Predictive health plan optimization for users of a network-based health care service

ABSTRACT

A computing system can obtain a corpus of health records for a user based on received user credential information by accessing a plurality of heath record systems. The system can initiate a health record verification process to enable the user to verify each of the obtained health records, and subsequent to the health record verification, resulting in a verified set of health records for the user, the system can present, on a display screen of a computing device of the user, a set of one or more risk mitigation providers or health plans based at least in part on the verified set of health records of the user.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of priority to each of U.S.Provisional Application No. 63/277,889, filed on Nov. 10, 2021, U.S.Provisional Application No. 63/326,076, filed on Mar. 31, 2022, and U.S.Provisional Application No. 63/403,193, filed on Sep. 1, 2022; theaforementioned priority applications being hereby incorporated byreference in their respective entireties.

BACKGROUND

Health record access is typically provided through individual healthcare providers, healthcare organizations, insurance companies,pharmacies, pharmacy benefit managers, and others. It is nearlyimpossible for any individual to construct and access a central recordrepository from these disparate sources. Health care services areprovided by health care providers through health care plans, which canvary in coverage, cost, deductibles, quality, and copays. Individualsare typically tasked with obtaining their own health care plans.

Call sessions between users and call agents for health care services mayrequire extensive information gathering and verification of personalhealth and medical history information to enable a system to determinean optimal health care plan for the user. Such information gathering andverification can correspond to the user’s personal information andmedical history (e.g., past medical conditions, current medicalconditions, past and current prescriptions, diagnoses, and the like).

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure herein is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings in which likereference numerals refer to similar elements, and in which:

FIG. 1 illustrates computing system implementing health prediction andplanning service for users, in accordance with examples describedherein;

FIG. 2 is a flow chart describing a method of providing a health historycompilation, dispute, and risk mitigation planning service, according tovarious examples;

FIG. 3 is a flow chart describing a method of utilizing health recorddata to tailor health-related services for users, according to variousexamples;

FIG. 4 illustrates a computing system implementing automatic healthrecord compiling, code translation, and dynamic scripting for callagents in connection with a health service, in accordance with examplesdescribed herein;

FIGS. 5A and 5B are example script interfaces presented to a call agentduring a call session with a user, according to various examples;

FIG. 6 is a flow chart describing a method of dynamic scripting during acall session between a call agent and a user, according to variousexamples;

FIG. 7 illustrates a computing system implementing automatic healthrecord compiling, code translation, health prediction, and health planranking for users, in accordance with examples described herein;

FIGS. 8A through 8D depict example interactive agent interfacespresented to a call agent during a call session with a user, accordingto various examples;

FIGS. 8E through 8H depict example interactive user interfaces presentedto users to implement one or more processes described herein;

FIG. 9A is a flow chart describing a method of optimizing health plansfor users, according to various examples;

FIG. 9B is a flow chart describing another method of optimizing healthplans for users, according to various examples;

FIG. 10 illustrates a computing device of a call agent communicating inreal time with the computing systems described herein, according toexamples described herein;

FIG. 11 illustrates a computing device of a user communicating in realtime with the computing systems described herein, according to examplesdescribed herein; and

FIG. 12 is a block diagram that illustrates a computer system upon whichexamples described herein may be implemented.

DETAILED DESCRIPTION

A computing system can compile health records for users that mayencompass all of the users’ health care visits, diagnoses, treatments,prescriptions, test results, insurance claims, and other health-relatedinformation. In certain implementations, a user can access the healthrecords via an executing application on the user’s computing device orvia website through a browser. In some examples, the user can set up anaccount with the computing system and provide credential information,such as a username or a phone number with a link, code or password.Using the credential information, the user can log into the system toinitially access health record information from a plurality of healthrecord systems, such as hospital appointment and/or visit records,diagnosis information, treatment information, prescription information,past health procedures (e.g., surgeries, screening, tests, etc.), andthe like.

Upon receiving a health record request from a user, the computing systemcan utilize the credential information of the user to access the healthrecord systems of each health service provider of the user and/or theinsurance claims and vendor databases that contain the user’s healthdata, and obtain the user’s health records. It is contemplated that thehealth records of the user may comprise technical terms or codes (e.g.,current procedure terminology (CPT) codes, health common procedurecoding system (HCPCS) codes, internal classification of diseases (ICD)codes, internal classification of functioning, disability, and health(ICF) codes, diagnostic-related group (DRG) codes, national drug codes(NDC codes), code on dental procedures and nomenclature (CDT),diagnostic and statistical manual of mental disorder (DSM) codes,generic and brand drug names, medical terminology for diagnoses andprocedures, hierarchical condition category (HCC) scores, riskadjustment factor (RAF) scores, national council for prescription drugs(NCPDP) and national provider identifier (NPI) codes, etc.) that may bedifficult or impractical for a typical user to decipher.

According to examples provided herein, the computing system can processand translate the health records of the user to generate anindividualized user interface (e.g., an app interface or web browserinterface) that provides the user with plain language summaries of theuser’s health records. For example, each health record may becategorized based on type (e.g., procedures, diagnoses, prescriptions,treatment plans, etc.), and classified based on one or more additionalcriteria (e.g., by doctor, by date, by health insurance provider, byhealth care service location or area (e.g., hospital address), etc. Invarious implementations, the computing system can initiate a healthrecord verification process with the user to verify that the user’shealth records are complete and accurate.

For example, in an initial verification process, the computing systemcan present the user with a set of interactive content features thatquery the user of whether a set of health records are accurate (e.g., ifthe user remembers a hospital stay, a prescription, or procedure). Whenpresented with plain language information corresponding to a particularhealth record, if the user is unable to remember or requires moreinformation, the computing system can present the user with additionalcontextual information associated with the health record, such as animage of a prescription drug, a non-generic brand name(s) of anequivalent drug, the generic name of an equivalent drug, an address of ahealth care facility, last fill date, last prescriber, and the like, inorder to stimulate the user’s memory.

In further implementations, the computing system can process the user’shealth records to identify any anomalies or records that do not appearconsistent with other records or which may have potential for user harm.For example, a user may have a set of health records consistent with acurrent set of diagnoses, prescriptions, and/or treatment plans, and thecomputing system may identify an anomalous health record indicating aninconsistent prescription for a drug that may have an adverse reactionto another drug the user has been prescribed. In such an example, thecomputing system may prioritize the verification of such anomaloushealth records for the user.

In certain examples, the user may input additional information for aparticular health record, such as a frequency of use for a prescriptionor over-the-counter medication. In such examples, the computing systemmay prompt the user to provide additional information that may be usefulfor the various health-related services described herein. Furthermore,the user may be provided with comprehensive access to health data fromall of the user’s providers, a feature that is not readily possible withcurrent implementations. It is contemplated that enabling users toprovide additional contextual information regarding their health carecan make up for lack of context in current insurer coding procedures forrecord-keeping, and can also provide the system with additionalinformation not available in current insurer records, such as use ofover-the-counter drugs, supplements, dietary information, etc., whichcan be processed by the system to determine factors such as adverse druginteractions.

When a health record is disputed by the user, the computing system caninitiate a dispute process to reconcile the disputed record. In certainimplementations, the computing system can provide forms and/or links toguide the user through the dispute process with a relevant health recordsystem to resolve the discrepancy. In such implementations, thecomputing system provides via the user interface all necessary documentsthat the user is to fill out and can guide the user in submitting thedocuments to the correct entities. In further examples, the computingsystem can create a set of content features that enables the user toprovide all necessary information, and automatically fills out thenecessary documents for submission. In such examples, the computingsystem can act as a dispute portal that enables the user to provide thenecessary information and submit the documents via the user interfacepresented on the executing application or website.

The dispute process can be performed for any type of health recorddispute. For example, during the health record verification process, theuser may be tasked with reviewing the user’s healthcare providers (e.g.,physicians, nurses, nurse practitioners, physician’s assistantsdentists, podiatrists, pharmacists, etc.), pharmacies, diagnoses,medical procedures, prescriptions, visited health care facilities,health insurance providers, and the like. As an example, the user maydispute a medical record indicating that the user has visited aparticular healthcare provider, or a request an amendment to a medicalrecord indicating that the user has been prescribed with a particulardrug. The computing system can facilitate the user in configuring adispute request, submitting the necessary information to the relevanthealth record system, performing any further back-and-forthcommunications, and ultimately resolve each disputed health record.

It is contemplated that subsequent to the health record verification anddispute resolution processes, the user will have a more accurate andcomplete health record that enables health service providers to providehighly tailored risk mitigation products and health care services forthe user. In various implementations, the computing system cancontinually receive updated health information from its user-base, andcompile a historical record of health information for each user. Infurther implementations, the computing system can execute healthcorrelation and prediction logic on the historical data to identifyvarious combinations of symptoms, diagnoses, prescription medications,treatments, health care quality (e.g., individual doctors), etc. toidentify, for any given user, a set of potential health risks that theuser faces given the user’s current health information.

For example, the computing system can process a user’s health recordinformation and identify any adverse factors, such as prescription andover the counter drugs that may have adverse reactions or a currenttreatment program for one medical condition that may be adverse to adifferent medical condition of the user’s. For any adverse factors inthe user’s health records, the computing system can provide an alert tothe user and any informational material indicating studies or currentmedical research indicating or describing the adverse factor. Thecomputing system may further predict a set of future health outcomes ofthe user given the user’s current health record and current healthtrajectory, and in certain examples, provide the user with individuallytailored information (e.g., a newsletter or medical publications) thatmay provide the user with greater awareness of the current and predictedhealth risks and outcomes accordingly.

In various implementations, the computing system can execute planningand recommendation logic to individually tailor health care planning forthe user based on the user’s verified health record information. Forexample, based on the predicted health risks or outcomes for the user,the computing system can utilize historical health care data to providethe user with financial planning recommendations, diet and exerciserecommendations, optimal health care and risk mitigation plans (e.g., anoptimal health insurance policy and one or more optimal doctors),lifestyle recommendations (e.g., whether the user should move to alocation at which family members may be readily available), optimalhealth care facilities, and the like. The historical health care datacan provide an indication of anticipated health care costs for the userbased on the predictions, and can enable the computing system tooptimize a health care plan for the user in order to, for example,minimize the anticipated costs while providing the user with adequate orsuperior care.

In various implementations, the computing system can further providerisk mitigation plan recommendations based on the user’s health history.For example, users may be provided with Medicare plan recommendations,as well as auto insurance and life insurance plan recommendations. Otherusers may also be provided with non-Medicare insurance planrecommendations based on their individual health record information. Infurther implementations, the computing system can provide doctorrecommendations based on the user’s current or predicted health risks.For example, if the user is predicted to have a particular health issueor currently has a particular health issue (e.g., diabetes, skincancer), then given the user’s health insurance coverage, the computingsystem can provide the user with a list of doctors that specialize inthe health issue and/or have been surveyed to be in a top percentile ofdoctors for the health issue, including but not restricted to specifichealth outcome metrics (e.g., medical and surgical error rates).

In further implementations, the computing system can provide a socialsupport network by matching users with other users experiencing similarhealth issues or having similar health risks. For example, based on theuser’s predicted and/or actual health risks and diagnoses, the computingsystem can identify one or more additional users, and provide anotification to each of the user’s indicating the match. In someaspects, the matched users can be provided with messaging and othercontact methods to provide the users with a social support platform forthose dealing with similar health issues.

Additionally, the computing system can continuously update a centralrepository that comprises the health records from all health recordsources for the user. In one example, the computing system automaticallypolls the health record databases for any updated information for theuser, such as new health care visits, prescriptions, and diagnoses. Inadditional examples, the computing system can further update a catalogof health-related literature based on current or recently conductedresearch, clinical trials, and treatments that may be relevant to theuser. Accordingly, if the user qualifies for a particular clinical trialor research program, the computing system can transmit a notificationindicating the clinical trial or research program to the user’scomputing device to enable the user to participate in the clinical trialor research program. It is contemplated that this information may be ofparticular interest to clinical sponsors and research programs.

In various examples, the computing system can utilize user reviews(e.g., survey data of health care providers, insurers, physicians,etc.), the health records of users, and the outcomes and progressions oftheir diseases to predict ratings of various health care providers andinsurers (e.g., star ratings of Medicare providers). Furthermore, byproviding a central repository of user health records and the varioushealth services described herein, the system may facilitate in drivinghigher adherence by reminding the user to fill and take drugs asprescribed, to schedule medical appointments and visit their doctors, toadhere to medical tests, and the like. The system can further facilitatein medical therapy management for users, which can comprise an extensionof adverse drug monitoring and adherence monitoring.

Examples described herein achieve a technical effect of integrating thehealth records of users from multiple health data systems in a singleapplication-based service to provide individually tailored healthservices. Current embodiments typically require patients to access eachof the user’s health care providers through individual portals of eachhealth care provider. Using secure network technology-enabling access tohospital systems, insurer portals, pharmacies and pharmacy benefitmanagement systems, government portals, healthcare enterprise resourceplanning (ERP) systems, Blue Button APIs, and other databases-thecomputing system described herein can provide the user with a single,integrated health care portal for all of the user’s health careproviders. In doing so, the computing system can utilize the corpus ofthe user’s health records-as well as historical health data relating tohealth risks, health care, costs, diagnoses, and treatments-to optimizehealth and risk mitigation services of the user.

In further examples, a computing system can execute a customer relationsmanagement system to implement dynamic assistance for call agents,particularly during health coverage plan calls with users requiringhealth care coverage or wishing to improve upon their current healthcare coverage or other related health care service offerings. In variousimplementations, the computing system can receive survey datacorresponding to current patient experiences with their current healthcare plans. The survey data can indicate whether the patients aresatisfied with their plans and which aspects or benefits of their planscould be improved upon (e.g., copays, deductibles, assigned or selecteddoctors, health care facilities, prescriptions, health care quality,etc.). The survey data can be obtained over time to improve upon thecomputing system’s current capabilities (e.g., machine learningcapability) in providing optimal health care coverage recommendations,along with additional personal information of a user (e.g., the user’shealth care records and history, demographic information, preferences,location, age, and the like).

In some examples, the computing system can obtain publicly available,third-party information of potential users, or can obtain permissionsfrom potential users to acquire information such as, but not limited to,household income, household size, demographic information, age andgender of household members, home locations, social media information(e.g., indicating lifestyle), and the like. The computing system canutilize this information to identify potential users that may wish toupdate their health care coverage. In further examples, the computingsystem may also obtain the health records of a potential user-given theappropriate authorizations from the user-to further identify potentialusers that may wish to update their health care coverage. The computingsystem can process the survey data, third-party information, and/orhealth record information of the potential users in order to prioritizecontact lists for call agents associated with a health care serviceimplemented by the computing system.

In additional examples, the user may take a cognitive assessment testprior to a call session with a call agent, which can be monitored andprocessed by the computing system to determine the cognitive abilitiesof the user, such as, but not limited to, spatial reasoning, motorfunction, word finding, and language processing abilities for the user.Further description of the cognitive assessment test may be found in PCTApplication No. WO2021/262609 A1, titled “Computing System Implementinga Cognitive-Based Risk Assessment Service for Motor Vehicle RiskDetermination,” filed on Jun. 21, 2021, which is incorporated herein byreference in its entirety. As described herein, the results of thecognitive assessment test can be utilized by the computing system fordynamic scripting purposes in a call session between the user and a callagent, along with the additional information described below.

As provided herein, prior to or during a call session with a call agent,the user can provide certain information for processing by the computingsystem. For example, the user may provide authorizations (e.g., during acall session or via a website prior to a call session) to enable thecomputing system to obtain the user’s health records from any number ofhealth care sources. These health records can include, withoutlimitation, the user’s history of health care visits, diagnoses,treatments, prescriptions, test results, insurance claims, and otherhealth-related information. In some examples, the user can set up anaccount with the computing system and provide credential information,such as, but not limited to, a username or a phone number with a link,code, or password. Additionally or alternatively, the user can provideany permissions and/or credentials during a call session with the callagent. Using the credential information, the computing system can accesshealth record information from a plurality of health record systems,such as, but not limited to, hospital appointment and/or visit records,diagnosis information, treatment information, prescription information,past health procedures (e.g., surgeries, screening, tests, etc.), andthe like.

In various implementations, the computing system can utilize thecredential information of the user to access the health record systemsof each health service provider of the user and/or the insurance claimsand vendor databases that contain the user’s health data, and obtain theuser’s health records. It is contemplated that the health records of theuser may comprise technical terms or codes (e.g., current procedureterminology (CPT) codes, health common procedure coding system (HCPCS)codes, internal classification of diseases (ICD) codes, internalclassification of functioning, disability, and health (ICF) codes,diagnostic-related group (DRG) codes, national drug codes (NDC codes),code on dental procedures and nomenclature (CDT), diagnostic andstatistical manual of mental disorder (DSM) codes, generic and branddrug names, medical terminology for diagnoses and procedures,hierarchical condition category (HCC) scores, risk adjustment factor(RAF) scores, national council for prescription drugs (NCPDP) andnational provider identifier (NPI) codes, etc.) that may be difficult orimpractical for a typical user and/or call agent to decipher.

According to examples provided herein, the computing system can processand translate the health records of the user to generate a dynamicscripting interface for the call agent in connection with a call sessionwith a user. Depending on the current information obtained by thecomputing system with respect to the user, the computing system canpresent the dynamic script for the call agent with multiple goals havingmultiple tiers of priorities. In certain examples, the computing systemcan execute scripting logic and/or a machine learning model todynamically respond to information acquired prior to and during a callsession in order to dynamically update the scripting interface for thecall agent.

As an example, an initial motive of the scripting logic may be to createan emotional connection and/or trust between the call agent and user.Depending on the current information available to the computing system,the scripting logic may identify one or more topics for the user toenable the call agent and user to establish a conversational tone inwhich the call agent seeks to provide the user with increasedsatisfaction with regard to the user’s health care coverage and/or callagent experience. Such a topic may include, without limitation, theuser’s personal interests (e.g., as determined from the third-partydata), current health issues, family health issues, health history, costconcerns, coverage concerns, and the like. Depending on the availableinformation pertaining to the user (e.g., acquired prior to or duringthe call session), the scripting logic can prefill the dynamic scriptinginterface to include, without limitations, known information of theuser, such as the user’s age, gender, date of birth, age, current healthcare coverage, home address, work address, occupation, and the like. Indoing so, the scripting logic may execute voice-to-text logic forprefilling, or can provide text input boxes in relevant locations on theinterface to enable the call agent to manually enter such information.

Once the appropriate permissions are received from the user, thecomputing system can obtain, process, and translate the codedinformation of the user’s health records in real-time to provide thecall agent with prepopulated portions of the dynamic scripting interface(e.g., with plain language summaries of the user’s health records), aswell as additional scripting for the call agent to progress the call.During this information gathering phase of the call, the scripting logiccan progress the dynamic script to enable the computing system toidentify specific items related to the individual include, withoutlimitation, any diseases, symptoms, medications, and/or otherinformation about pertaining to the user that may affect the user’schoice for a health care coverage plan, any future financial choices,and/or future living choices of the user (e.g., relocating to be closerto family and/or higher quality health care). Further information to bescripted involves identifying the user’s allergies, prescriptions,current health care providers, and pharmacies used by the user,including determining whether the user is satisfied with the user’scurrent healthcare arrangement.

During the call session, and as additional information of the user isbeing gathered throughout the call, the computing system can dynamicallyscore various attributes and benefits of any number of health carecoverage plans. Identifying the most optimal plan(s) for a user is anon-trivial undertaking, with current implementations being morereactive to the patient’s current health issues, age, gender, andaffordability. Furthermore, there exists more than sixty-thousanddifferent health care plans, each providing a unique set of benefits,copays, deductibles, health partnerships, etc. that may be selected by auser or a suggested to the user by a call agent. The result of notproviding the patient with the most optimal health care plan that ismost tailored to the user’s current situation and predicted healthoutcomes can be increased cost, lack of coverage, poor healthcareaccess, lower quality care, worse health outcomes, and uncertainty forthe user. Furthermore, many people may lack the digital skills requiredfor obtaining health records, translating the records to be readable inplain language, and/or filling out forms in complicated navigation treesto find an optimal health care plan.

Accordingly, while the general state of the health care coveragetechnology is moving towards more automation and independence for theuninsured or those seeking new insurance coverage to do research andacquire coverage on their own, there is a current need for providingfast and robust assistance to users such that the users have confidencethat the assistance process results in the most optimal health carecoverage for them on an individual basis. To fulfill this need, thecomputing system can operate in conjunction with the call agent during acall session to provide dynamic scripting for the call agent based oninformation pertaining to the user received in real-time, continuouslyprogressing the call session on the front end while simultaneouslyscoring the various attributes and benefits of health care coverageplans and ranking those plans based on the user’s information. This bothminimizes the necessary time required for a call session in determiningthe most optimal coverage plan for the user and eliminates the need forusers to log onto a health coverage app or website to enter informationand navigate through various screens on their own.

As the call session progresses, the computing system can determine anyadverse factors of the user’s current prescriptions, including, withoutlimitation, any prescription drugs that may cause significant druginteractions (e.g., rendering other drugs or vaccines less effectiveand/or causing adverse reactions). In doing so, the computing system canidentify prescription equivalents for the user that eliminate or reducesuch adverse factors. Upon determining these non-adverse prescriptions,the scripting logic can update the scripting interface so the call agentcan provide the user with alternative prescriptions that may improve theuser’s lifestyle.

The computing system may further predict a set of future healthcareutilizations and health outcomes of the user given the user’s currenthealth record and current health trajectory. In some examples, thecomputing system can process all acquired information pertaining to theuser, including, without limitation, survey data concerning individualdoctors and health care facilities, health predictions (e.g., futuredisease, symptoms, treatments, etc.), and user preferences to determinea “circle of care” for the user. A “circle of care” refers to healthcare coverage that covers the entire current and future needs of theuser, based on the user’s current health and predicted health outcomes.For example, if the computing system predicts, based on all availableinformation pertaining to the user, that the user should have coveragethat encompasses endocrinological care, the scripting logic will providethe call agent with language indicating so to the user, and thecomputing system will score endocrinological coverage higher in theavailable health care plans for the user. Furthermore, the computingsystem can identify gaps in the current health care coverage of theuser, and the scripting logic can update the scripting interface toallow the call agent to discuss such gaps with the user. Still further,the computing system, scripting logic, and scoring logic can take intoaccount any preferences of the user, with the scoring logic providingweightings in the stack-rankings of health care plans based on theuser’s preferences (e.g., when the user indicates that endocrinologicalcoverage is not needed or is less desirable for the user). When the useris amenable to filling those gaps, the call agent can indicate so in thescripting interface, and the computing system can update the scoring andrankings of health care plans accordingly.

In further implementations, the computing system can execute interactivevoice recording (IVR) technology that actively monitors the call sessionfor triggers that causes the scripting interface, health outcome andhealth care utilization predictions (e.g., a probability of futurediagnosis or whether the user will require additional medications), andhealth care plan rankings to be updated, as described in detail below.In utilizing IVR, the computing system can detect when a user providespermission to obtain health records from any number of health recorddatabases (e.g., detecting a voiced affirmation or when the userprovides a required input on the user’s phone). The computing system canfurther monitor the call session for emotional responses and answersfrom the user to the call agent’s questions to update the dynamic scriptand health plan rankings.

It is contemplated that the computing system’s convergence on a mostoptimal health care plan for the user will seek to maximize theindividually tailored coverage for the user (e.g., based on the user’sbudget, current state of health, predicted health outcomes, etc.) whileminimizing the cost of such coverage. It is further contemplated thatpreventative care using such individually optimized plans can result insignificantly reduced overall costs across a population.

In one example, a call session may be initiated by a call agent with auser who has taken a cognitive assessment test with the computingsystem. During the call, a scripting interface is presented on acomputing device of the call agent, who may perform the call over anetwork link on the computing device or on a typical telephone (e.g., alandline or cellular phone). The scripting logic can process currentlyobtained information of the user (e.g., name, age, gender, weight,height, home address, etc.) to update the scripting interface toestablish a conversational tone (e.g., an emotional or identifiableconnection) with the user. If the computing system has not receivedauthorization to access the user’s health records, the scripting logiccan update the dynamic script to ask for such permissions and anynecessary login information, access codes, links, passwords, etc. In oneexample, the user can link the user’s access to various health systemdatabases via a website or user application provided by the computingsystem.

While the call progresses, the computing system can utilize the user’spermissions to access the user’s health records from the health systemdatabases in real-time, and provide analysis including, withoutlimitations, translating the coded records (e.g., CPT and ICD codes fordetermining the user’s prescriptions and diagnoses), and updating thescoring of health care plan benefits and health care plan rankings. Thecomputing system can further identify the user’s current prescriptionmedications, past and current treatment plans, diagnoses, current healthcare providers, past medical procedures (e.g., surgeries), and the like.Concurrently, the scripting logic can proceed with determining whetherthe user is planning to move, where the user’s family is located (e.g.,in case the user will need support), any current symptoms the user isexperiencing, any exercise routines of the user, and any other relevantinformation for ultimately determining an optimal health care coverageplan for the user. The computing system can further process thisdynamically acquired information to identify any coverage gaps (e.g.,unnecessary or overly expensive copays, out-of-scope prescriptions,probable future coverage needs) in the user’s current health carecoverage. The scripting logic can enable the call agent to discuss suchgaps with the user and determine whether the user wishes to close thegaps in coverage.

The call agent can provide inputs on the scripting interface indicatingthe user’s answers, which the computing system processes in real-time toupdate the health plan scoring and rankings. In some examples, thecomputing system can identify where the user is excelling in health forthe user’s age and/or gender (e.g., a low number of prescriptions, goodBMI, good blood pressure, overall health, etc.) and the scripting logiccan provide celebratory scripting for the call agent, such that the useris provided with positive feedback regarding the user’s good healthand/or health habits. In certain implementations, the computing systemcan monitor the call for any abnormalities or emotive responses toprovide further scripting for the call agent. The user is further ableto decline certain coverages for any reason (e.g., the user is on a dietor nutrition plan, or due to increased cost), and the computing systemupdates the scoring and rankings of health plans accordingly.

In still further implementations, the computing system can process theuser’s health records and any information provided by the user and/orcall agent to determine a “digital skill” level for the user, or howsavvy the user may be in operating computing devices, apps, websites,using video conferencing, receiving and responding to electronicmessages, and the like. This digital skill level may be utilized by thecomputing system in filtering through health care coverage plans thatare more geared towards telehealth visits or checkups over a computerversus in-person visits. At any given time during the call session, thecomputing system can determine an optimal health care plan for the user,and the scripting logic can intervene to instruct the call agent topropose the plan for the user. It is contemplated that the moreinformation received regarding the user, the more precise the computingsystem can converge on an optimal health care plan for the user.However, certain overarching concerns can cause a particular health careplan to be ranked highest (e.g., robust coverage for a certain type ofcancer), which can result in time savings for both the user and callagent. The scripting logic can indicate that no further information isneeded and that a most optimal plan has been found for the user.

For certain users in the United States, the computing system can furtherfilter health care coverage plans to include or prioritize Medicareplans, as well as certain types of auto insurance and/or life insuranceplans. Furthermore, if the user has provided survey informationregarding a particular health care plan, one or more doctors, and/or oneor more health care facilities, the computing system can determine a setof preferences for the user, and update the health plan scoring andrankings accordingly.

According to additional examples described herein, a computing systemcan execute a customer relations management system to implement dynamicassistance for users of a health service. A call agent can initiate acall session with a user, who can provide certain information forprocessing by the computing system. For example, the user may provide anauthorization (e.g., during a call session or via input on a website orapplication interface prior to or during the call session) to enable thecomputing system to obtain the user’s health records from any number ofhealth care sources. These health records can include, withoutlimitation, the user’s history of health care visits, diagnoses,treatments, prescriptions, test results, insurance claims, and otherhealth-related information. In some examples, the user can set up anaccount with the computing system and provide credential information,such as, but not limited to, a username or a phone number with a link,code, or password. Additionally or alternatively, the user can provideany permissions and/or credentials prior to or during a call sessionwith the call agent. Using the credential information, the computingsystem can access health record information from a plurality of healthrecord systems, such as, but not limited to, hospital appointment and/orvisit records, diagnosis information, treatment information,prescription information, past health procedures (e.g., surgeries,screening, tests, etc.), and the like.

In various examples, the computing system can automatically process andtranslate the health records of the user to generate a live agentinterface for the call agent in connection with a call session with auser. Depending on the current information obtained by the computingsystem with respect to the user, the computing system can present thelive agent interface on a computing of the call agent, which candynamically update based on inputs provided by the call agent during thecall session with the user. The live agent interface can comprise a setof input features that enables the call agent to provide inputs based oninformation provided by the user during the call session. As providedherein, the real-time inputs provided by the call agent can comprisinginput data for a health plan ranking engine, which can execute one ormore optimization techniques to output a personalized ranking of healthcare plans for the user.

As provided herein, a “call session” can comprise any interactivesession between the call agent and the user, which can includetelephonic communications, text messaging, email, live application-basedmessaging, video conferencing, and any combination of the foregoing. Forexample, a call session can comprise a telephonic call from a call agentto a user in combination with an interactive user interface beingpresented to the call agent on a computing device. As the call sessionprogresses and more information is provided by the user, a backendcomputing system can process the additional information and dynamicallygenerate a personalized health plan ranking for the user.

Once the appropriate permissions are received from the user, thecomputing system can obtain, process, and translate the codedinformation of the user’s health records in real-time to provide thecall agent with an interactive agent interface that enables the callagent to input filters for the ranking of health plans. For example, theinteractive interface can ensure that crucial information regarding theuser’s preferred doctors, pharmacies and necessary prescriptions, andcurrent and predicted diagnoses are inputted into the interactive agentinterface, such that the computing system can accurately optimize aranking of health care plans for the user.

During the call session, and as additional information of the user isbeing gathered throughout the call, the computing system can dynamicallyscore various attributes and benefits of any number of health carecoverage plans. As described herein, the computing system operates inconjunction with the call agent during a call session to provide theinteractive agent interface that supports the progression of the callsession while scoring the various attributes and benefits of health carecoverage plans and ranking those plans based on the user’s information.As the call session progresses, the computing system can automaticallydetermine any adverse factors of the user’s current prescriptions,including, without limitation, any prescription drugs that may causesignificant drug interactions. In doing so, the computing system canidentify prescription equivalents for the user that eliminate or reducesuch adverse factors. Upon determining these non-adverse prescriptions,the scripting logic can update the scripting interface so the call agentcan provide the user with alternative prescriptions that may improve theuser’s lifestyle.

Furthermore, the computing system can identify gaps in the currenthealth care coverage of the user, and the health care plan rankings canallow the call agent to discuss such gaps with the user and discuss orotherwise provide information to the user concerning plans that fillsuch gaps. Still further, the interactive agent interface can provideinteractive features corresponding to any preferences of the user, withthe scoring logic providing weightings in the stack-rankings of healthcare plans based on the user’s preferences (e.g., when the userindicates that endocrinological coverage is not needed or is lessdesirable for the user). When the user is amenable to filling thosegaps, the call agent can indicate so in the interactive interface, andthe computing system can update the scoring and rankings of health careplans accordingly.

In an example, a call session may be initiated by a call agent with auser. During the call, an interactive agent interface is presented on acomputing device of the call agent, who may perform the call over anetwork link on the computing device or on a typical telephone (e.g., alandline or cellular phone). The call agent can reference theinteractive interface to ask questions to the user (e.g., asking for theuser’s required or preferred doctors, prescriptions and/or pharmacies,and current diagnoses), process currently obtained information of theuser (e.g., name, age, gender, weight, height, home address, etc.) toupdate the individualized health care plan rankings for the user.

During the call session, the call agent can provide inputs on theinteractive interface indicating the user’s answers, which the computingsystem processes in real-time to update the health plan scoring andrankings. In some examples, the computing system can identify where theuser is excelling in health for the user’s age and/or gender (e.g., alow number of prescriptions, good BMI, good blood pressure, overallhealth, etc.) and provide such information to the call agent via theinteractive agent interface., such that the user is provided withpositive feedback regarding the user’s good health and/or health habits.The user is further able to decline certain coverages for any reason(e.g., the user is on a diet or nutrition plan, or due to increasedcost), and the computing system updates the scoring and rankings ofhealth plans accordingly. In further implementations, the interactiveagent interface can present the call agent with a side-by-sidecomparison of the user’s current plan and each ranked health care planas ranked by the computing system.

At any given time during the call session, the computing system candetermine an optimal health care plan or optimal health care planranking for the user, and the interactive agent interface can be updatedto allow the call agent to present the optima plan or plan rankings forthe user. It is contemplated that the more information receivedregarding the user, the more precise the computing system can convergeon an optimal health care plan for the user. For Medicare users in theUnited States, the computing system can further filter health carecoverage plans to include or prioritize Medicare plans, as well ascertain types of auto insurance and/or life insurance plans.Furthermore, if the user has provided the call agent with informationregarding a particular health care plan, one or more doctors, and/or oneor more health care facilities, the computing system can determine a setof preferences for the user, and update the health plan scoring andrankings accordingly.

In further examples, a call session between a call agent and a user isnot required to perform the health outcome prediction and health planranking techniques described throughout the present disclosure. In suchexamples, a web portal or application interface is provided directly tothe user computing devices that enables the users themselves to navigateand provide the necessary authorization(s) and information that triggerthe computing system to obtain the user’s health records and perform thehealth prediction and health plan ranking processes described herein.

As used herein, a computing device refers to devices corresponding todesktop computers, cellular devices or smartphones, personal digitalassistants (PDAs), laptop computers, virtual reality (VR) or augmentedreality (AR) headsets, tablet devices, television (IP Television), etc.,that can provide network connectivity and processing resources forcommunicating with the system over a network. A computing device canalso correspond to custom hardware, in-vehicle devices, or on-boardcomputers, etc. The computing device can also operate a designatedapplication configured to communicate with the network service.

One or more examples described herein provide that methods, techniques,and actions performed by a computing device are performedprogrammatically, or as a computer-implemented method. Programmatically,as used herein, means through the use of code or computer-executableinstructions, and includes the implementation of machine learning and/orartificial intelligence to execute the processes described throughoutthe present disclosure. These instructions can be stored in one or morememory resources of the computing device. A programmatically performedstep may or may not be automatic.

One or more examples described herein can be implemented usingprogrammatic modules, engines, or components. A programmatic module,engine, or component can include a program, a sub-routine, a portion ofa program, or a software component or a hardware component capable ofperforming one or more stated tasks or functions. As used herein, amodule or component can exist on a hardware component independently ofother modules or components. Alternatively, a module or component can bea shared element or process of other modules, programs, or machines.

Some examples described herein can generally require the use ofcomputing devices, including processing and memory resources. Forexample, one or more examples described herein may be implemented, inwhole or in part, on computing devices such as local or remote servers(e.g., cloud computing infrastructure), desktop computers, cellular orsmartphones, personal digital assistants (e.g., PDAs), smartwatches,wearable and other remote patient monitoring technologies (e.g.,activity monitoring devices), laptop computers, VR or AR devices,printers, digital picture frames, network equipment (e.g., routers) andtablet devices. Memory, processing, and network resources may all beused in connection with the establishment, use, or performance of anyexample described herein (including with the performance of any methodor with the implementation of any system).

Furthermore, one or more examples described herein may be implementedthrough the use of instructions that are executable by one or moreprocessors. These instructions may be carried on a computer-readablemedium. Machines shown or described with figures below provide examplesof processing resources and computer-readable mediums on whichinstructions for implementing examples disclosed herein can be carriedand/or executed. In particular, the numerous machines shown withexamples of the invention include processors and various forms of memoryfor holding data and instructions. Examples of computer-readable mediumsinclude permanent memory storage devices, such as hard drives onpersonal computers or servers. Other examples of computer storagemediums include portable storage units, such as CD or DVD units, flashmemory (such as carried on smartphones, multifunctional devices ortablets), and magnetic memory. Computers, terminals, network enableddevices (e.g., mobile devices, such as cell phones) are all examples ofmachines and devices that utilize processors, memory, and instructionsstored on computer-readable mediums. Additionally, examples may beimplemented in the form of computer-programs, or a computer usablecarrier medium capable of carrying such a program.

System Description

FIG. 1 illustrates computing system 100 implementing health predictionand planning service for users, in accordance with examples describedherein. The computing system 100 can include a communication interface105 that connects the computing system 100, over one or more networks160, with health record systems 190 and computing devices 170 of users175. In certain examples, the computing devices 170 can includesmartphones, personal computers, etc., and can execute a designatedapplication 172 that provides a network connection to the computingsystem 100.

In various implementations, the users 175 can set up accounts with thecomputing system 100 and authorize the computing system 100 to accesshealth records of the users from the health record systems 190. Asprovided herein, the health record systems 190 can comprise computingsystems and databases of health care providers, insurance providers, andthe like. The computing system 100 can include a record compiler 120that transmits record requests to the health record systems 190 (e.g.,using credential information from the user 175). In certain examples,the user 175 can provide unique credential information, such as personalinformation (e.g., name, age, address, etc.), and usernames andpasswords (and/or other access information) for each of the user’shealth institutions (e.g., to enable the record compiler 120 to obtainthe user’s health records from each institution). Upon providing thecredential information, the record compiler 120 can access and obtainthe health record systems 190 of the health care institutions and/orhealth insurance companies of the user 175. Such health records can bedisputed by the user 175 and can correspond to insurance claims, insurerrecords, doctor records and/or notes, and the like. In variousimplementations, the record compiler 120 can periodically poll thehealth record systems 190 for any updated information pertinent to theuser 175.

In some aspects, the computing system 100 can include a database 115including a user profile 116 for each user 175, which can include theuser’s personal information and the entirety of the user’s health recordinformation. As described in detail below the user profile 116 of aparticular user 175 may be updated as new health records are obtainedand/or when a health record verification process confirms the user’shealth records as accurate and complete. The database 115 can furtherinclude historical data 117 that indicates various correlations betweenhealth conditions, health risks, treatments, prescriptions, diagnoses,health risks, lifestyles, nutrition and diet, location of residence,demographic information, longevity, and the like. The historical data117 can further include health research data indicating adverse impactsbetween prescribed medications, treatments, procedures, and the like.

The database 115 can further include health care provider data 118indicating doctor quality and/or effectiveness (e.g., based on surveydata and/or patient outcomes), health care institution quality (e.g.,for particular treatments and/or diagnoses), health care facilitylocations and quality, and cost information. In further examples, theprovider data 118 can further include survey data for health careproviders, individual doctors, health insurance providers, etc. toprovide understanding of any social determinant barriers to adequatehealthcare. The survey data may be collected from third-party resources,such as medical journals and/or public health resources, and/or may becollected through surveying the users 175 themselves.

In further examples, the record compiler 120 can provide surveys to theusers 175, which can prompt the users 175 to provide personal contextualinformation regarding their health care providers, insurers, physicians,etc. In various implementations, the survey data provided by theindividual users 175 can enable the health planning engine 145 to morespecifically tailor recommendations for risk mitigation plans and healthcare providers, and may further be utilized to determine ratings forhealth care providers, insurers, etc. In further implementations, a user175 can input their review of a doctor, drug, and/or service based onthe quality of care they received, which can be processed by the healthplanning engine 145 to provide health plan recommendations. Stillfurther, the user 175 may be permitted to find a new doctor based on arecommended or requested course of care. The user 175 may also beenabled to identify other courses of care, service, or drugs to discusswith their doctor based on the experiences of other patients.

In various examples, the computing system 100 can include a healthrecord parser 140 that receives and parses the health record data fromthe record compiler 120. In parsing the health record data for aparticular user 175, the health record parser 140 can execute codetranslation logic that translates the various nomenclature and codeinformation in which the health records are stored into plain languageinformation. For example, the health records of the user 175 may includeinformation relating to procedures performed on the user 175, diagnosisand disease information, disability information, prescriptioninformation, which may be stored as current procedure terminology (CPT)codes, health common procedure coding system (HCPCS) codes, internalclassification of diseases (ICD) codes, internal classification offunctioning, disability, and health (ICF) codes, diagnostic-relatedgroup (DRG) codes, national drug codes (NDC codes), code on dentalprocedures and nomenclature (CDT), diagnostic and statistical manual ofmental disorder (DSM) codes, hierarchical condition category (HCC)scores, risk adjustment factor (RAF) scores, national council forprescription drugs (NCPDP) and national provider identifier (NPI) codes,NCS numbers, doctor’s notes, lab data, images, self-assessments bypatients, genetic information, notes and treatment plans from nursinghomes, health-knowledge quiz results, etc. Genetic information can bedetermined from a genetic test (e.g., such as may be determined fromgenetic testing, if ordered by a doctor or provided by a user), and/orinferred based on health information provided by the user about hisfamily (e.g., parents, siblings, etc.). Genetic testing can includecommercial tests, as well as specific tests that link an individual to aparticular medical condition. Genetic information can further reflectpredispositions or probabilities. For example, the genetic informationcan reflect a determination that a user has a genetic predispositiontowards a medical condition based on a parent of the user having thesame medical condition. Some health information about the user may beprovided through manual input, such as by the user. Some information,such as doctor notes, can also be subject to optical characterrecognition (“OCR”).The health record parser 140 can execute translationlogic that translates these codes into plain language definitions ordescriptors.

As provided herein, the health records of a user 175 can includeprescriptions, doctors, and health-related conditions of the user 175,as well as the electronic health records of the user 175. The healthrecords can further include health claims of the user 175. The healthrecords can further include doctor’s notes pertaining to the user 175,which can be automatically converted by the health record parser 140.

When the user’s health records have been parsed and translated, thehealth record parser 140 can initiate a verification process with theuser 175 to enable the user to confirm or dispute each health record.For example, the health record parser 140 can generate content data thatcauses the computing device 170 of the user 175 to present anindividualized user interface that includes content comprising the plainlanguage translations of each health record. As provided herein, theuser interface can include confirmation requests for each of the user’shealth diagnoses, treatments, health care facility visits,prescriptions, and other health-related information pertaining to theuser 175.

In certain scenarios, the user 175 may be unable to recall informationcorresponding to a particular health record. For example, the userinterface may present a content screen or panel requesting the user 175to confirm a particular prescription that the user 175 does not recallbeing prescribed. As such, the content screen or panel can include aselectable feature (e.g., stating “I don’t recall”) that triggers thehealth record parser 140 to provide additional contextual informationrelated to the health record. In the case of a forgotten or mistakenlyprescribed prescription, the health record parser 140 can cause one ormore images related to the drug to be presented to the user 175, such asan image of a pill, a recognizable brand name equivalent of the pill, adescription of which health issue the drug is prescribed to treat, andthe like.

In attempting to stimulate the user’s memory, the health record parser140 can further provide additional contextual information to the user175, such as an original date at which the drug was prescribed, alocation and/or doctor that prescribed the drug, and image of the healthcare facility (e.g., an outdoor entrance facade) at which the drug wasprescribed, a name of the health care facility at which the drug wasprescribed, and the like. In some examples, the user’s memory may besuccessfully stimulated by the additional contextual information, andthe user 175 may confirm the health record or amend or dispute thehealth record. For example, if the user 175 is no longer taking theprescription, the user 175 may request that the health record be amendedto indicate that the prescription has been canceled.

It is contemplated that the memory stimulation techniques may beperformed for the user 175 for any particular health record, such asrecords indicating diagnoses, treatments, hospital visits, etc. The user175 may confirm the health record, refute the health record, or indicatea lack of memory or contextual information. In certain examples, thehealth record parser 140 can identify any anomalous health records thatdo not appear consistent with other health records, such as an anomalousprocedure or prescription that does not appear to relate to the user’sdiagnoses and treatments. Such anomalous health records may be flaggedfor the user 175 for verification with a contextual alert indicating theanomaly.

When the user 175 is confident that a health record is incorrect orshould not exist, a dispute module 130 of the computing system 100 caninitiate a dispute process for the user 175. A user interaction with theindividualized user interface may indicate trigger the dispute module130 to record or indicate the disputed health record in the user’sprofile 116, and generate a dispute query to be transmitted to therelevant health record system 190 storing the disputed health record. Insome aspects, the dispute module 130 acts as an assistant for the user175, providing links to forms or documents needed for the user 175 topursue the dispute, as well as instructions corresponding to whichentity to contact and submit the forms and documents. In alternativeaspects, the dispute module 130 can act as a facilitator and performauto-filling techniques for any particular form or document needed todispute a health record. For example, the dispute module 130 can prefillany boxes or form sections with known information stored in the user’sprofile 116, and can present a series of user interface features thatquery the user 175 for any necessary information that cannot beprefilled and automatically complete the form or document accordingly.In further examples, the dispute module 130 can also automaticallytransmit the necessary dispute documents to the relevant health recordsystem 190 or claims vendor to facilitate in resolving the dispute.

In further implementations, the health record parser 140 enables theuser 175 to readily update a list of medications prescribed to the user175. For example, the user 175 can remove stray medications that theuser 175 no longer uses or has replaced with another medication from adifferent health care provider. On the backend, the health record parser140 may automatically update the user’s health care providers with anychanges to the user’s medication list.

It is contemplated that medical record defects or health care fraud canresult in significant risks to patients, both physical and financial.For example, a fraudulent health record may be the result of identitytheft and can involve prescription drugs being sent to the wrong personunder the guise of an unknowing user 175. Accordingly, the health recordparser 140 and dispute module 130 facilitate in identifying anypotential health records that are incorrect or fraudulent, and canfurther provide pathways to finding the sources or perpetrators of suchincorrect or fraudulent information. In implementing the health recordverification and dispute processes, the health record parser 140 anddispute module 130 can create a more robust health record for the users175 such that subsequent health services can be more individuallytailored for the users 175.

Once such health service can comprise health prediction, which canprocess the user’s verified health records using the historical data 117and provider data 118 to generate a health risk profile for the user175. The computing system 100 can include a health outcome predictionengine 135 that utilizes the various correlations in the historical data117 and provider data 118 to generate the health risk profile for theuser 175 based on the user’s verified health records. For example, giventhe user’s health records-indicating the user’s current personalinformation (e.g., weight, age, height, ethnicity, gender or sex,demographics, location or residence, lifestyle, diet, etc.) as well asthe user’s current health care information (e.g., current diagnoses,treatments, prescriptions, previous screenings and medical and/orsurgical procedures, health care provider(s), doctor(s), etc.)-thehealth outcome prediction engine 135 can identify a set of correlationswith known patients having similar personal and health information.Further, health outcome prediction engine 135 can determinepredispositions (or probabilities) of the user towards having or nothaving a particular medical condition based on genetic informationdetermined or obtained about the user.

In examples, a user’s health risk profile 175 can also include aninference of a user’s medical condition based on current or pastdiagnosis or prescriptions. In such examples, the inference may beprobabilistic (e.g., likely, highly probable, etc.), to identify amedical condition that is not explicitly stated in the user’s medicalrecords. Further, based on the user’s health profile 175, the user’shealth profile can also make assumptions about the user’s life-style(e.g., user does not exercise). The health outcome prediction engine 135can also implement steps to confirm inferences, such as by generatingquestions for the user to confirm regarding the determined inferences.

In various implementations, the historical data 117 can comprise groundtruth information indicating the medical outcomes of patients that hadsimilar health records and personal information as the user 175. Thus,the health outcome prediction engine 135 can perform health recordmatching techniques to identify a set of probable health outcomes,health risks, life expectancy, and mortality risk for the user 175 basedon the user’s current information. In doing so, the health outcomeprediction engine 135 can generate and provide a set of healthpredictions for the user 175, such as a mortality table indicatingprobability of death within a certain timeframe and a set of healthrisks for particular diseases (e.g., various types of cancer, heartdisease, gastrointestinal disease, diabetes, respiratory diseases,Alzheimer’s disease, etc.). For example, based on the user’s currenthealth record information, the historical data 117, and the providerdata 118 of the user 175 (e.g., the user’s current doctor(s) and healthcare provider(s)), the health outcome prediction engine 135 can output aprediction that the user 175 is at risk of diabetes, heart disease,heart attack, and prostate cancer within the next three years.

In further implementations, the health outcome prediction engine 135 cangenerate a quantitative risk prediction for the user 175 based on theuser’s health records, such as a percentage risk of a medical problem,acute health emergency, or chronic condition over a future period oftime. The health outcome prediction engine 135 can further provide theuser 175 with additional information, such as the average risks of thesemedical issues for people with similar attributes of the user 175 (e.g.,similar age, weight, height, sex, etc.), as well as the average risksfor other populations of users. In some aspects, the health outcomepredication engine 135 can further generate, based on the user’s healthrecords and other information provided, a probability of the user 175requiring a particular medical procedure (e.g., surgery, treatmentprograms, etc.). The health outcome prediction engine 135 can furtherprovide the user 175 with average medical procedure probabilities forpeople with similar attributes to those of the user 175.

In further implementations, the health outcome prediction engine 135 canfurther process the verified health records of the user 175 to determineany adverse factors in which any of the user’s current prescriptionmedications, treatments, over-the-counter drugs and supplements, andhealth risks or current health issues may adversely impact other currentprescription medications, treatments, and health risks or current healthissues of the user 175. As an example, the user 175 may have medicationsprescribed from two different health care providers that may causeadverse reactions, side effects, or otherwise increase health risks tothe user 175. As another example, a current treatment for a chronicillness experienced by the user 175 may exacerbate another health issueof the user 175. For each detected adverse factor, the health outcomeprediction engine 135 can provide a notification or alert to the user175, which the user 175 can utilize to have a discussion with the user’shealth care providers and potentially alter a treatment or prescriptionaccordingly and eliminate the adverse factor. In further examples, thehealth outcome prediction engine 135 can identify any prescribedmedications or over-the-counter medications or supplements that arepotentially unsafe for the user 175 (e.g., based on the user’s age).

It is contemplated that active user engagement with accurate healthoutcome predictions provides critical awareness for the user’s inreducing or mitigating health risks and promoting longer, healthierlives. In various implementations, the computing system 100 can includea health planning engine 145 that can utilize the generated predictions,profile data of the user 175, and/or provider data 118 to interact withthe user 175 in planning physically and financially for medicalprocedures and treatments, selecting optimal health care providersand/or individual doctors based on the health outcome predictions,providing highly tailored health-related literature for the user 175(e.g., updated newsletters pertaining to the user’s current healthissues and risks), and providing health risk mitigation and preventionservices for the user 175. The computer system 100 can, for example,include or access a collection of content items, including journals (orsummaries), wellness articles and other content items, where suchcontent items are categorized to medical conditions or attributes ofusers. In some variations, the categorizations can be programmaticallydetermined using, for example, key words, semantic classifiers, and/orlanguage processing. Further, the computing system can include processesto compile and/or such publications into an individualized newsletter(or content aggregation) for the user. As an addition or alternative,the personalized content aggregation can encompass topics such asfinancially planning and social outreach (e.g., social platforms) thatare specific to medical conditions or other attributes (e.g., goodhealth) of individual users.

In certain examples, the newsletter may include features that prompt theuser 175 for input regarding the user’s health experience with aparticular health care provider. The user’s input information may beshared with insurers so, for example, current insurers can identifyusers 175 seeking assistance to provide those users 175 with modified oradditional preventative care before complications occur (e.g., diseaseprogression that requires lengthy hospital stays). In further example,the newsletter prompts may also affect an insurer’s rating (e.g.,Medicare star rating), and can incentivize insurers to identifysubstandard care and, for example, move resources to certain users 175before formal rating surveys are sent, which other insurers can accessand target users 175 that are having negative experiences with theircurrent insurance plans. In some aspects, the newsletter may alsointroduce a gamification system (e.g., including monetary andnonmonetary rewards, score system, leaderboard, etc.) to incentivizeusers 175 to engage with the individualized health education content andsurveys described herein.

In an initial planning phase, the health planning engine 145 can processthe user’s verified health records to identify the current health risksand predicted health outcomes facing the user 175. Based on thisinformation, the health planning engine 145 can present a set ofrecommended risk mitigation plans for the user 175, which can includerecommended health insurance plans, life insurance plans, automobileinsurance plans, etc. The recommended risk mitigation plans can compriseplans that provide maximum care for the user 175 based on affordabilityfor the user 175, which may be actively queried or inferred based on theuser’s personal information. In various examples, the health planningengine 145 can further utilize the historical data 117 to accuratelypredict the future costs of health care for the user for anticipatedscreenings, treatments, medications, and procedures, etc. In suchexamples, the health planning engine 145 can generate content data thatcauses the user interface presented on the user’s computing device 170to indicate the predicted costs and potential areas of savings in theuser’s health records, and enable the user 175 to plan financially forfuture medical expenses.

In one example, the health planning engine 145 can identify less costlydrug equivalents for the user’s prescription medications that would notadversely affect the user 175. In further examples, the health planningengine 145 can provide a recommended health care plan (e.g., a healthinsurance plan) or health care provider for the user 175 that wouldresult in lower costs with minimal impact to health care quality.Conversely, the health planning engine 145 may determine that the user175 may be able to afford a more expensive, higher quality health careplan that may provide added health treatment benefits than lower costplans. In providing plan recommendations, the health planning engine 145may query the user 175 for personal financial information, expenditures,liabilities, income, assets, etc. to determine an affordability factorfor the user 175 in order to make more robust health recommendations.

The health planning engine 145 can further process the user’s profiledata to determine one or more health care preferences of the user 175,such as the particular qualities in a doctor or health care that theuser 175 highly values (e.g., bedside manner, cost, popularity, etc.).Based on the user’s insurance coverage, health issues and risks, andpreferences, the health planning engine 145 can determine an optimalhealth care provider and individual doctor for the user 175 and providethe user 175 with information indicating the match. As an example, auser 175 with diabetes may prefer a doctor that is rated highly by otherpatients and that provides exceptional care for patients with diabetes.The health planning engine 145 can parse through the provider data 118to identify an optimal doctor that matches the user’s preferences andspecializes in diabetes care.

In various implementations, the health planning engine 145 can engagewith the user 175 through one or more health planning sessions toprovide customized lifestyle recommendations that would mitigate orreduce the current and predicted health risks of the user 175. Forexample, the health planning engine 145 may determine that the user 175will require physical assistance in the near future, and recommend thatthe user 175 relocate to an area or residence where family or friendsmay provide the necessary assistance. In a further example, the healthplanning engine 145 can provide more granular lifestyle recommendations,such as dietary recommendations (e.g., eliminating certain foods fromthe diet), exercise recommendations (e.g., taking a thirty minute walkevery morning and evening), stress reduction recommendations (e.g.,starting a mentally relaxing hobby, such as gardening, cooking, orplaying a musical instrument), and the like.

According to some examples, the health planning engine 145 can furtherprovide the user 175 with customized health knowledge based on theuser’s health record information to promote lifestyle changes thatreduce the user’s health risks. The health planning engine 145 canfurther act as a health assistant to the user 175, providingnotifications via the designated application 172 for recommendedroutines, medication adherence, scheduled medical appointments, and thelike. As such, the health assistance services provided by the healthplanning engine 145 can integrate the user’s verified health recordinformation into the health assistance service such that therecommendations provided to the user 175 are more individually tailoredto meet specific health goals that current implementations.

In certain implementations, the health planning engine 145 can providethe user 175 with a health consciousness score or general health scorethat continually updates based on the user’s interactions with thehealth planning engine 145, updates to the user’s health records (e.g.,a recent visit indicating improved vitals, such as blood pressure, bloodtest results, cholesterol levels, gut health, cognitive test results,and the like), risk adjustment factor (RAF), and the user’s diagnosesand or ICD codes. The health consciousness score or general health scorecan be based on the user’s current health status as indicated in theuser’s health records as well as the user’s diligence in seekingpreventative care. In some aspects, the health consciousness scoreand/or general health score can be adjusted based on the user’s age,sex, and other attributes and/or factors.

Methodology

FIGS. 2 and 3 are flow charts describing a method of providing a healthhistory compilation, dispute, and risk mitigation planning service, anda method of utilizing health record data to tailor health-relatedservices for users, according to various examples. In the belowdiscussion of FIG. 2 , reference may be made to reference characterscorresponding to like features as shown and described with respect toFIG. 1 . Furthermore, the steps described in connection with FIG. 2 neednot be performed in any particular order, and any step described may beprecede or may be performed subsequent to any other step. Referring toFIG. 2 , the computing system 100 may receive credential data and ahealth record request from a computing device 170 of a user (200). Asdescribed herein, the credential data can include a HIPAA authorization(202) and personal user information, such as usernames, passwords,access information, etc. to access the user’s health records fromvarious health record databases (203). The personal information can beutilized by the computing system 100 to access the health systemdatabases and obtain a corpus of the user’s health records over a giventime period (e.g., the previous two years). In certain examples, thecomputing system 100 can provide a two-step authentication feature foradditional security (204).

According to examples provided herein, the computing system 100 canverify the user’s credential information and obtain and translate thehealth records of the user 175 (205). In various implementations, thehealth records can comprise the user’s health care provider information(e.g., the user’s doctors, health insurance, current health insuranceplan, visited medical facilities, etc.) (207). The health records canfurther comprise the user’s prescription data indicating which prior andcurrent prescription drugs the user 175 has been prescribed (208). Thehealth records can further comprise the user’s medical history data,including health care facility visits, diagnoses, treatments, procedures(e.g., screenings, surgeries, etc.), and the like (209). As describedabove, the health records may be stored in coded format using a numberof health code protocols. The computing system 100 can be programmed orcan execute code translation logic to convert the health records intoplain language.

In various examples, the computing system 100 can initiation a healthrecord verification and dispute process by transmitting display data tothe computing device 170 of the user 175, where the display data causesthe computing device 170 to present an interactive user interfaceenabling the user to verify and/or dispute health records (210). Ininstances in which the user 175 is unable to remember a particularhealth record, the computing system 100 may cause the interactive userinterface to present memory triggers, such as images and contextualinformation corresponding to the health record, as described above(212). The interactive user interface can provide selection featuresthat enable the user 175 to verify or dispute a particular health record(214).

Based on a dispute trigger for a particular health record, the computingsystem 100 can initiate a dispute process with the relevant healthrecord system(s) (215). In doing so, the computing system 100 canfacilitate in provide the necessary documents and/or links that enablethe user 175 to submit a dispute request. In variations, the user 175 isenabled to perform the dispute process through the interactive userinterface, while the computing system 100 executes automated formfilling and submission techniques for the user 175. In implementing theverification and dispute processes for the user 175, the computingsystem 100 facilitates in compiling a robust and accurate medicalhistory for the user 175.

Based on the user’s health record data, the computing system 100 cangenerate content data providing optimal risk mitigation plans for theuser 175 (220), such as health insurance plans (222), life insuranceplans (224), and automobile insurance plans (223). The optimal riskmitigation plans can be determined based on the user’s current medicaldiagnoses and treatment needs, cost, and locale. In variousimplementations, based on user input on the interactive user interface,the computing system 100 can connect with risk mitigation providers tocreate and/or cancel risk mitigation plans for the user 175 (225).

Referring to FIG. 3 , the computing system 100 can store ground truthhealth data of a user base (300). The ground truth health data cancomprise screening, diagnosis, treatment, and procedure information foreach of the users 175 (302). The ground truth health data can furthercomprise health care provider data, indicating which health careproviders each user 175 utilizes for health care (303). The ground truthhealth data can further include health outcome data, indicating whetherthe user 175 recovered from a particular diagnosis and treatment, thenature of the recovery, side-effects, lasting impacts on the user’slivelihood, how long the recovery took, mortality information, and thelike (304). The ground truth health data also includes personalinformation, such as each user’s age, weight, height, gender or sex,demographic information (e.g., income, residence, genetic background,etc.). As such, each user 175 or a subset of the users 175 for which ahealth records exist and health outcomes are known, can comprise acontrol group that enables the computing system 100 to predict healthoutcomes of a present user based on the ground truth health data.

In various implementations, the computing system 100 can generate a setof health outcome predictions for the user 175 based on the user’sverified health record data and the ground truth health data (305). Thehealth outcome predictions can indicate any adverse interactions betweenmedications, treatments, current health issues and risks, andover-the-counter supplements and drugs (307). The health outcomepredictions can further indicate any chronic or acute health risksfacing the user 175 over a given time frame (e.g., the next five years)(309). In further examples, the computing system 100 can provide theuser with a set of recommendations, such as foods and/or activities toavoid, or foods and/or activities to consume and perform (e.g., healthyfoods, exercise routines).

Based on the health outcome predictions, user preferences, and/or surveydata, the computing system 100 can generate an optimized health plan forthe user 175 (310). The optimized health plan can include recommendedhealth care providers that are highly rated and/or meet the preferencesof the user 175 (e.g., doctors specializing in treating an ailmentsuffered by the user 175) (312). The optimized health plan can alsoinclude a financial plan based on a set of estimated costs the user 175is expected to pay for medical expenses over a given time frame (313).The optimized health plan can further include lifestyle recommendationsbased on current research that would prevent or reduce health risksassociated with the health outcome predictions for the user 175 (314).

In various examples, the computing system 100 can further provide apatient-to-patient interaction platform that enables the user 175 toconnect and interact with other users 175 having similar health issues,risks, or outcome predictions (315). It is contemplated that socialinteraction between like users 175 can result in increased motivation topursue preventative and mitigative health behaviors that can increasehealth wellness and longevity. In certain examples, the computing system100 can further provide individually tailored health literature based onthe health outcome predictions of the user 175 (320). Such healthliterature is often technical in nature, using medical terminology thatmay not be readily decipherable by a typical user 175. Accordingly, thecomputing system 100 can parse the literature (e.g., research journalsand clinical trial results) to provide plain language summaries of suchpublications (322).

In certain examples, the targeted health literature for the user 175 mayinclude clinical trial information that is pertinent to the user 175based on the user’s 175 medical records (324). In such examples, thecomputing system 100 may determine that the user 175 qualifies as acandidate for a particular clinical trial, and can match the user 175with the clinical trial (325). For example, the computing system 100 canprovide contact information for the clinical trial and facilitatecommunications with those performing the trial.

System Description

FIG. 4 illustrates a computing system implementing automatic healthrecord compiling, code translation, and dynamic scripting for callagents in connection with a health service, in accordance with examplesdescribed herein. The computing system 400 can include a communicationinterface 405 to communicate, over one or more networks 460, withthird-party databases 480, health record systems 490, agent computingdevices 467, and computing devices 470 of users 475 of a network-basedhealth service. In various implementations, the computing system 400 canfurther include a dynamic scripting engine 445 that communicates withthe agent computing devices 467 to provide a script interface 468 thatcall agents 465 may interact with during call sessions with users 475.

In certain examples, the users 475 can access the network-based healthservice via a health service application 472 or a website on theircomputing devices 470 to provide personal information, view and selecthealth care coverage plans, link health care accounts (e.g., to enablethe computing system 400 to compile health records of the user 475), andprovide survey data 417 corresponding to the user’s current health carecoverage. In certain examples, the users 475 can access the healthservice to provide survey data 417 including, without limitation, theusers’ personal experiences, preferences, and/or shortcomings of theircurrent health care plans, such as experience with doctors, health carefacilities, costs, health care service, customer service, and the like.The computing system 400 can further include a database 415 for storinguser profiles 416 of the users 475, the survey data 417, a full suite ofhealth care coverage plans 418, and one or more machine learning models419 for optimizing the scoring and ranking of health care coverage plansfor each user 475.

When a user 475 provides the appropriate permissions, a data compilerand translator 420 of the computing system 400 can access health recordsystems 490 of health care providers and insurers of the user 475 toobtain the health records of the user 475. In various examples, the datacompiler and translator 420 can automatically translate the codes inwhich the health records are formatted stored to, for example, providethe user 475 with plain language translations of the user’s healthrecords, and perform the health care coverage optimizations describedherein. In various examples, the computing system 400 can also include ahealth prediction engine 435 that can process the health records, andany additional information of the user 475 (e.g., location,demographics, age, weight, etc.) to generate one or more healthpredictions for the user 475, which can be stored and periodicallyupdated in the user profile 416 of the user 475.

As provided herein, the health records can be obtained by the healthrecord translator 420 when the user 475 links or otherwise synchronizesaccounts of the health record systems 490 with the computing system 400.For example, the user 475 can access the health application 472 orwebsite of the health service implemented by the computing system 400and provide login information, relevant passwords, and/or otherauthorizations to enable the health record translator 420 to access theuser’s health records from the health record systems 490. In variousimplementations described herein, this information can also be providedto a call agent 465 during a call session with the user 475.

In certain implementations, the data compiler and translator 420 canfurther access third-party databases 480 to compile additional userinformation, such as census databases, social media services, searchengine databases, and the like. Such information can include anypublicly available information of the user 475 as well as informationobtained based on authorizations provided by the user 475, such aslifestyle information, income and other financial information, and thelike. Such information can also be stored in the user’s profile 416, andutilized by the computing system 400 in prioritizing leads for the callagents 465 in contacting users 475 who may be interested in obtaining orchanging health care coverage.

In some examples, the user profile 416 can include information that ispredictive of whether a particular user 475 would be interested inchanging health care coverage. For example, the user profile 416 mayinclude information indicating that the user 475 has recently moved oris planning on moving to a new location. The user profile 416 mayfurther indicate whether the user 475 has received a pay increase and/orwhether the user 475 has lost government benefits for purchasing healthcare coverage (e.g., subsidies, expired coverage, moving from governmentemployment to private employment, etc.). In prioritizing leads for callagents 465, the computing system 400 can calculate a confidence scorefor listed users 475 indicating, based on all gather information, aprobability or confidence interval that the user 475 will change ahealth care coverage plan or obtain a new health care coverage plan.Accordingly, when a call agent 465 accesses the script interface 468, aprioritized list of users 475 can be presented with contextualinformation concerning each of the users 475, and/or the probability orconfidence interval indicating a likelihood that the user 475 willengage with the call agent to purchase an optimal health care coverageplan.

When a call agent 465 initiates contact with a user 475, the call agent465 can interact with a script interface 468 presented on an agentcomputing device 467. The dynamic scripting engine 442 of the computingsystem 400 can dynamically communicate, over the one or more networks460 with the dynamic scripting engine 445, which can generate a scripton the script interface 468 for the call agent in real time based onacquired information. The script interface 468 can initially present theuser’s personal information, any useful contextual information (e.g.,the user 475 has reached retirement age and is eligible for Medicare,the user 475 has moved to a new location, the user 475 has had a recentchange in a family situation, and the like). In certain examples, thedynamic scripting engine 445 can execute call monitoring logic toprogrammatically monitor the interactions between the call agent 465 andthe user 475, and adapt the dynamic scripting accordingly. For example,the dynamic scripting engine 445 can monitor the conversation todetermine when to provide script language for general conversation,information gathering, transitions, and providing a ranked list ofhealth care plans. In certain implementations, the dynamic scriptingengine 445 can further determine an emotional state of the user 475during the call at any given time, or the call agent 465 can provideinputs indicating the user’s emotional state, which can comprisetriggers for the dynamic scripting engine 445 in generating the scriptfor the call agent 465.

During the call session, the scripting engine 468 can provide the callagent with the actual words to say to the user 475, and/or can providesuggested questions and responses as an assistance tool for the callagent 465. In one example, as the call session progresses, the callagent 465 can provide inputs on the script interface 468 to, forexample, input information provided by the user 475 and indicate when aparticular information gathering task has been completed (e.g., when theuser 475 has provided authorization to access the user’s healthrecords). As input data is provided by the call agent 465 via the scriptinterface 468, the dynamic scripting engine 445 can process the inputsto continue progressing the script for the call agent 465.

Once the user 475 provides the necessary authorizations to access theuser’s health records, the data compiler and translator 420 can accessthe relevant health record systems 490 to obtain the user’s healthrecords. For example, the data compiler and translator 420 can executeIVR monitoring to detect when the user 475 assents to a vocal requestfor health record access, or can respond to an input from the call agent465. As described above, the health records may be stored in coded form,such as CPT codes for indicating the user’s prescription information andICD codes for indicating the user’s historical diagnoses. In real time,the data compiler and translator 420 can execute code translation logicto process the coded information in the health records and provide plainlanguage translations of the coded data to the dynamic scripting engine445, which can automatically populate the script interface 468 withplain language information concerning the user’s health records.

In conjunction with the scripting engine 445 updating the scriptinterface 468 for the call agent 465, the health prediction engine 435and ranking engine 440 can also process the user’s health record data(HRD) to generate a set of health predictions for the user 475 and beginscoring the various benefits and/or attributes of available health plans418 to begin converging on a most optimal health plan 418 for the user475 respectively. In certain aspects, the dynamic scripting engine 445can further update the script interface 468 for the call agent 465 toask the user 475 if the user 475 is experiencing any currentdifficulties, if the user 475 has any short or long-term health goals,whether the user 475 is able to take time off from work for health carefacility visits, whether the user 475 requires mobility orhealth-related assistance or would prefer assistance, whether the userprefers a particular language for the user’s health care providers anddocuments, and the like. Each of the health prediction engine 435, theranking engine 440, and the dynamic scripting engine 445 can process theuser’s responses to these questions and update the health outcomepredictions, health plan rankings, and dynamic script accordingly.

In further examples, the dynamic scripting engine 445 can instruct thecall agent 465 to verify certain aspects of the user’s health recorddata, such as, without limitation, whether the user 475 is currentlyusing all prescribed drugs, the last few appointments or visits tohealth care facilities, previous health screenings and diagnoses, thecurrent state of diagnoses, current treatment plans, and the like.Additionally or alternatively, the computing system 400 can communicatewith the user’s doctors or other health care providers to verify theuser’s health records.

The dynamic scripting engine 445 can further identify any gaps in healthcare coverage for the user 475 based on the obtained information, suchas a lack of diabetes coverage or a lack of endocrinological care in theuser’s current health care plan. The script interface 468 can be updatedto enable the call agent 465 to discuss these gaps in coverage to theuser 475 and determine whether the user 475 wishes to close these gaps.These gaps in coverage may also comprise predicted gaps in coveragebased on the health outcome predictions generated by the healthprediction engine 435. Thus, the script interface 468 can enable thecall agent 465 to discuss potential future health issues with the user475 and whether the user 475 wishes to address the predicted healthissues with a health care plan 418 that provides adequate or superiorcoverage for the predicted health issues.

In further examples, the dynamic scripting engine 445 can identify theuser’s current health care plan based on the health record data, andprompt the call agent 465 to discuss any shortcomings in the user’scurrent health care plan. In doing so, the health plan ranking engine440 can identify health care plans 418 that provide more effectivecoverage (e.g., higher quality and/or lower out-of-pocket costs), whichthe dynamic scripting engine 445 can process to update the scriptinterface 468 and enable the call agent 465 to provide the user 475 withspecifics regarding the shortcomings of the user’s current health careplan and the advantages of other health care plans 418 that may be moreoptimal for the user’s current and predicted health situation.

Based on the user’s responses, which may be monitored by the dynamicscripting engine 445 or inputted on the script interface 468 by the callagent 465, the ranking engine 440 can update the health plan rankings toreflect the user’s preferences. Each health care coverage plan 418 has aunique set of attributes and benefits, such as costs, disease coverages,partnerships with health care providers, preferred or available healthcare facilities and hospitals, doctor selections and/or associations,preventative care services, etc. As information is compiled throughinput data from the call agent and via the data compiler 420, theranking engine 440 can score each of the benefits and attributes of eachhealth care plan 418 and generate a dynamic ranking of health care plans418 as additional data is processed. Accordingly, in real time, the callagent 465 can view a current ranking of health care plans 418 on thescript interface 468 and can provide the ranking to the user 475 at anytime (e.g., via voice, text message link, email, app or website portal,etc.).

As provided herein, the ranking engine 440 can score health planbenefits and attributes based on affordability (e.g., based on theuser’s current financial information, such as income and expenses),deductibles and copays, familial coverage, the user’s current health(e.g., current treatments, diagnoses, prescriptions, etc.), completing acircle of care for the user 475 and/or user’s family, predicted healthissues for the user 475, and/or the user’s own preferences (e.g., asdetermined via the call session and/or any survey data completed by theuser 475). The user 475 can select from a list of highest ranked healthplans 418 and/or can opt to choose the highest ranked, most optimalhealth plan 418, which can trigger a process between the user 475 cancall agent 465 to cancel the user’s current plan and/or enroll in theselected or most optimal plan 418.

It is contemplated that any of the dynamic scripting engine 445, rankingengine 440, and health prediction engine 435 can execute one or moremachine learning models 419 to continuously improve their functionsdescribed herein. Such machine learning models 419 may be tailored andadapted to provide increasingly effective and/or efficientcommunications between the call agent 465 and user 475, as well asimproved health predictions and health plan rankings that arepersonalized depending on the unique attributes of each user 475.

Example Script Interface

FIGS. 5A and 5B show an example script interface 500 presented to a callagent during a call session with a user, according to various examples.The script interface shown in FIGS. 5A and 5B can correspond to thescript interface 468 as shown and described with respect to FIG. 4 , andcan be presented on an agent computing device 467 in real timecommunication with the computing system 400 of FIG. 4 . Furthermore, inthe below description of FIGS. 5A and 5B, reference may be made toreference characters representing various features and componentsdescribed with respect to FIG. 4 . Referring to FIG. 5A, the scriptinterface 500 can be presented to the call agent 465 and specify theuser 475 that the call agent is contacting. The computing system 400 canobtain any current information of the user 475 and automaticallypopulate certain fields of the script interface 500 for the call agent465, such as personal information fields (e.g., indicating date ofbirth, the user’s home location, familial information, income details,and any known information about the user’s health records.

In various examples, the script interface 400 can include a healthrecord data panel 415 that is to be populated by the user’s healthrecord information when obtained. In the example shown in FIG. 4A, thecall agent 465 has yet to receive the necessary permissions to accessthe relevant health record systems 490 to obtain the user’s healthrecords. The script interface 500 can include a dynamic script panel 505that provides the call agent 465 with a script for conversing with theuser 475. As provided herein, the computing system 400 dynamicallygenerates the script based on currently acquired information andprogresses the call session to obtain additional information of the user475 that can result in a precise ranking of health plans for the user475. As the call agent 465 and user 475 converse, the computing system400 can monitor the call using IVR and auto-populate various fields ofthe script interface 500 based on the user’s responses, and/or thescript interface 500 can provide functionality to enable the call agent465 to input details of the user 475.

In further examples, the script interface 500 can present descriptiveconnections between particular health conditions and/or prescriptionsand specific health plan benefits. As such, the script interface 500 canprovide the call agent 465 with tools and/ resources (e.g., search toolsor automatic contextual information) that allow the call agent 465 tounderstand relevant conditions based on the user’s health records. Instill further examples, the dynamic script 505 can automatically presentfollow-up questions for the call agent 465 that enables the call agent465 to acquire more information from the user 475, such as the severityof a particular health condition.

The script interface 500 can further include a health plan ranking panel510 that provides a health plan ranking (e.g., in real time) for thecall agent 465 based on all currently acquired information of the user475. In the example shown in FIG. 5A, the call agent 465 is tasked withpresenting a conversational tone with the user 475 while advancing thecall session in a strategic manner, such that the necessary informationfrom the user 475 is received naturally and in a sincere manner.

Referring to FIG. 5B, the script interface 500 has been updated based onthe progression of the call session, with each of the dynamic scriptpanel 505, the health record data panel 515, and the health plan rankingpanel 510 having been updated based on newly obtained informationpertaining to the user 475. As shown in the dynamic script panel, 505,the call agent 465 and user 475 have discussed authorization to obtainthe user’s health records, which has been granted by the user 475. Uponreceiving the authorization, the backend computing system 400automatically accesses the health record systems 490 and obtains theuser’s health records. The computing system 400 also automaticallytranslates the coded health records and populates the health record datapanel 515 accordingly.

Furthermore, based on the health record data being obtained, thecomputing system 400 can automatically update the health plan rankings510 for the user 475. As provided herein, the dynamic script 505 cancontinue with the goal of obtaining any additional relevant information(e.g., identifying any gaps in the user’s current coverage, determiningthe user’s health goals, moving situation, whether the user 475 would beinterested in relocating closer to family, and the like). As shown inthe script interface 500, and based on the user’s current information,the computing system 400 has determined that the most optimal plan forthe user 475 is a specific special needs plan that is highly tailored tothe user’s unique medical and health situation. At a later stage of thecall session, the call agent 465 and user 475 can discuss the top plans418 for the user 475 and initiate a process to cancel the user’s currentplan and/or purchase a plan 418 that is selected by the user 475.

Methodology

FIG. 6 is a flow chart describing a method of dynamic scripting during acall session between a call agent 465 and a user 475, according tovarious examples. In the below discussion of FIG. 6 , reference may alsobe made to reference characters representing certain features andcomponents as shown and described with respect to FIGS. 4, 5A, and 5B.Furthermore, the processes described with respect to FIG. 6 may beperformed by a backend computing system 400, agent computing device 467,or a combination of both. Still further, while the steps in FIG. 6 areshown in a specific order, each step described may be performed priorto, in conjunction with, or subsequent to any other step. Referring toFIG. 6 , the computing system 400 can detect a call session beinginitiated between a call agent 465 and a user 475 (600). In response todetecting the call session being initiated, the computing system 400 canobtain any current information pertaining to the user (e.g., as accessedthrough third-party databases 480, such as driving records, census data,social media data, demographic information, income data, etc.) (605),and generate a dynamic script 505 on a script interface 500 presented onthe agent’s computing device 467 (610).

As the call agent 465 and user 475 converse, the computing system 400can receive authorization to access the user’s health records (615). Forexample, the computing system 400 can automatically detect the user 475providing approval and/or authorization during the call session (617),or can receive authorization based on call agent input (619). In furtherexamples, the user 475 can link various health accounts with thecomputing system 400 that enables the computing system 400 to access theuser’s health records.

The computing system 400 then obtains and translates or decodes theuser’s health records from the relevant health record systems 490 (620).As described above, the health records may be in coded form, such as CPTand ICD codes for the user’s prescription and diagnoses information(621). Thus, the computing system 400 automatically translates the codesinto plain language and auto-populates the call agent’s script interface500 accordingly. As further described above, the health records of theuser 475 can describe the user’s prescription information as well asprovide a full corpus of the user’s medical history. The prescriptioninformation can include the user’s prescription fill history (622),which comprises all prescribed medications, prescription schedules,prescription lapses or cancelations, and/or dates and times whenprescriptions are filled (e.g., indicating whether the user 475 istaking medications as prescribed). The user’s medical history caninclude the user’s medical claim history, which can comprise all paymentrequests submitted to the user’s insurance provider(s), any copays forhealth care facility visits or pharmacy orders, and/or insurance claimsmade by the user 475.

As the call session continues to progress, the call agent 465 can beprovided with a script to determine any additional relevant user data(625), such as income information (627), current and/or future livinginformation (628), and/or the user’s health-related goals and anypreferences, such as preferred doctors, health care facilities,pharmacies, etc. (629). In certain examples, the computing system 400can further generate health outcome and health care utilizationpredictions for the user 475 based on the user’s current information andmedical history (630). For example, a health record indicating that theuser 475 is overweight or obese may be predictive of a future diagnosisfor diabetes and/or predictive that the user 475 will require one ormore prescriptive medications at some point in the future. In furtherexamples, the health care utilization predictions can providelikelihoods or probabilities that the user 475 will require additionalmedical items including, without limitation, health care facilityvisits, screenings, treatment plans, prescriptions, and the like. Asinformation is obtained, the computing system dynamically ranks healthplans 418 for the user 475 (635).

The result is the most optimal plan for the user 475 being ranked at thetop of the health plan ranking panel 510 of the script interface 500.The call agent 465 can provide the list to the user 475, either verballyor via electronic communication (e.g., text link, email, etc.).Thereafter, the user 475 can view the details of each plan (e.g.,coverages, copays, deductibles, health care facilities, doctors,prescriptions, etc.) and choose a plan that is most suitable to theuser’s needs and concerns. It is contemplated that when individuals arepaired with health care plans that are optimized to their unique needsand health situations, health care costs to the user 475 as well ascosts to society may be dramatically reduced while increasing thequality of care.

System Description

FIG. 7 illustrates a computing system 700 implementing automatic healthrecord compiling, code translation, health prediction, and health planranking for users, in accordance with examples described herein. Thecomputing system 700 can include a communication interface 705 tocommunicate, over one or more networks 760, with third-party databases780, health record systems 790, agent computing devices 767, and/orcomputing devices 770 of users 775 of a network-based health service. Asprovided herein, the call agents 765 can operate agent computing devices767 to present an interactive agent interface 768 that provides the callagents 765 with supportive information for each call session, such asdynamic scripting and interactive features that enable the call agent765 to provide inputs based information received from the user 775and/or the user’s health records.

In certain examples, the users 775 can access the network-based healthservice via a health service application 772 or a website on theircomputing devices 770 to provide personal information, view and selecthealth care coverage plans, link health care accounts (e.g., to enablethe computing system 700 to compile health records of the user 775),provide survey data corresponding to the user’s current health carecoverage, and the like. In certain examples, the users 775 can accessthe health service to provide survey data including, without limitation,the users’ personal experiences, preferences, and/or shortcomings oftheir current health care plans, such as experience with doctors, healthcare facilities, costs, health care service, customer service, and thelike. The computing system 700 can further include a database 715 forstoring user profiles 716 of the users 775, survey data, a full suite ofhealth care coverage plans 717, and historical health data 718 that canindicate health correlations that enable a health prediction engine 735of the computing system 700 to predict a particular user’s health careneeds over a future time frame (e.g., with the next year).

When a user 775 provides the appropriate permissions (e.g., a HIPAAauthorization provided verbally and selected by the call agent 765 onthe interactive agent interface 768, and/or a blue button selection bythe user 775), a data compiler and translator 720 of the computingsystem 700 can access health record systems 790 of health care providersand insurers of the user 775 to send record requests and obtain thehealth records of the user 775. In various examples, the data compilerand translator 720 can automatically translate the codes in which thehealth records are formatted stored to, for example, provide the user775 and/or call agent 765 with plain language translations of the user’shealth records, and perform the health care coverage optimizationsdescribed herein. In various examples, the computing system 700 can alsoinclude a health prediction engine 735 that can process the healthrecords, historical health data 718, and any additional information ofthe user 775 (e.g., location, demographics, age, weight, etc.) togenerate one or more health predictions for the user 775, which can bestored and periodically updated in the user profile 716 of the user 775.

As provided herein, the health records can be obtained by the healthrecord translator 720 when the user 775 links or otherwise synchronizesaccounts of the health record systems 790 with the computing system 700.For example, the user 775 can access the health application 772 orwebsite of the health service implemented by the computing system 700and provide login information, relevant passwords, and/or otherauthorizations to enable the health record translator 720 to access theuser’s health records from the health record systems 790. In variousimplementations described herein, this information can also be providedto a call agent 765 during a call session with the user 775.

In certain implementations, the data compiler and translator 720 canfurther access third-party databases 780 to compile additional userinformation, such as census databases, social media services, searchengine databases, and the like. Such information can include anypublicly available information of the user 775 as well as informationobtained based on authorizations provided by the user 775, such aslifestyle information, income and other financial information, and thelike. Such information can also be stored in the user’s profile 716, andcan be utilized by the computing system 700 in prioritizing leads forthe call agents 765 in contacting users 775 who may be interested inobtaining or changing health care coverage.

When a call agent 765 initiates contact with a user 775, the call agent765 can interact with an interactive agent interface 768 presented on anagent computing device 767. In some aspects, the interactive agentinterface 768 can include a dynamic script that the call agent 765 mayreference in communicating with the user 775. Additionally oralternatively, the interactive agent interface 768 can present the callagent 765 with a set of interactive features that the call agent 765 canupdate based on the progression of the call session with the user 775.

In various examples, once the user 775 provides the necessaryauthorizations to access the user’s health records, the data compilerand translator 720 can access the relevant health record systems 790 toobtain the user’s health records. In some examples, the data compilerand translator 720 can execute IVR monitoring to detect when the user775 assents to a vocal request for health record access, or can respondto an input from the call agent 765. In further examples, theauthorization can be provided via a texted link that, when selected bythe user 775, provides the data compiler and translator 720 with thenecessary authorization to access the user’s health records. Asdescribed above, the health records may be stored in coded form, such asCPT codes for indicating the user’s prescription information and ICDcodes for indicating the user’s historical diagnoses. In real time, thedata compiler and translator 720 can execute code translation logic toprocess the coded information in the health records and present plainlanguage translations of the coded data to the call agent 765 via theinteractive agent interface 768.

In certain examples, the call agent 765 can further verify certainaspects of the user’s health record data, such as, without limitation,whether the user 775 is currently using all prescribed drugs, the lastfew appointments or visits to health care facilities, previous healthscreenings and diagnoses, the current state of diagnoses, currenttreatment plans, and the like. Additionally or alternatively, thecomputing system 700 can communicate with the user’s doctors or otherhealth care providers to verify the user’s health records.

In various implementations, the health prediction engine 735 can processthe user’s health record data and historical health data 718 to generatea set of health predictions for the user 775. Specifically, the healthprediction engine 735 can execute a machine learning model and/orimplement artificial intelligence techniques that process health recorddata of a particular user 775 and historical health data 718 of anynumber of patients to generate a set of health predictions for the user775. For example, the health prediction engine 735 can identify anycorrelations between the user 775 and any number of other patients’historical health information (e.g., age, demographics, geneticbackground, gender, similar lab results, diagnoses, and prescriptivemedications, etc.) to generate the set of health predictions for theuser 775. The health predictions can further include predicted healthcare requirements and coverage needs for the user 775 over a future timeperiod. In further implementations, the health prediction engine 735 canutilize the health outcome predictions to further predict a set offuture health care needs of the user 775, future medications, medicaldevices (e.g., a wheelchair or CPAP), etc. The health prediction engine735 can further estimate a set of costs for the user 775 based on thisinformation, and can provide the estimated costs and predictions to theranking engine 740, which can provide the user 775 and/or call agent 765with a recommended health care plan accordingly. In still furtherimplementations, the ranking engine 740 can utilize aggregated anonymousdata to determine known health outcomes of patients for a health carenetwork or group of doctors to further generate the health planrankings. In further examples, CMS data and star rankings can further beutilized to generate the health plan rankings.

As provided below with respect to FIGS. 8A through 8D, the interactiveagent interface 768 can be updated with information provided by thecomputing system 700 (e.g., based on the user’s health records), and canguide the call agent 765 to request additional information, such aswhich doctors the user 775 wishes to keep (e.g., primary care doctor andspecialists), which medications and pharmacies the user 775 wishes tokeep, and any current or potentially future diagnoses of the user 775.As the call agent 765 and user 775 discuss such information, the callagent 765 can input the information into the interactive agent interface768, which can affect the predictions generated by the health predictionengine 735 and/or the health plan rankings generated by the rankingengine 740. Accordingly, the inputs provided by the call agent 765 arereceived by each of the health prediction engine 735 and the optimizer742 of the ranking engine 740 as input data, which are processed by eachto update the health predictions and health plan rankings accordingly.

As provided herein, the user’s health records can indicate a set of pastand current diagnoses, lab results, treatments, and/or prescriptions ofthe user 775. In certain implementations, the health prediction engine735 can identify historical health records in the historical health data718 that include the same or similar diagnoses, lab results, treatments,and/or prescriptions, and determine whether this information leads tofurther diagnoses, treatments, and/or prescriptions. The healthprediction engine 735 can further filter the historical records based onthe user’s personal information, such as age, gender, geneticinformation, and the like, and can determine the actual health outcomesof the individuals associated with closely matching historical healthrecords. The health prediction engine 735 may then determine a set ofprobable health outcomes for the user 775, which can include futuretreatments, diagnoses, likely medications, health coverage needs, andthe like. In some aspects, the health prediction engine 735 canassociate each predicted health outcome (e.g., future diagnosis,treatments, prescription, etc.) with a probability or probabilisticscore, which can be utilized by a ranking engine 740 to score or applyweightings to the various benefits and attributes of the health plans717 for the user 775.

In various implementations, the ranking engine 740 of the computingsystem 700 can execute an optimizer 742 (e.g., a machine learning orartificial intelligence application) using the health predictions of theuser 775 from the health prediction engine 735 and the health records ofthe user 775 to score the various benefits and/or attributes ofavailable health plans 717 for the user 775. In certain aspects, thecall agent 765 can reference a dynamic script presented on theinteractive interface 768 to ask the user 775 if the user 775 isexperiencing any current difficulties, if the user 775 has any short orlong-term health goals, whether the user 775 is able to take time offfrom work for health care facility visits, whether the user 775 requiresmobility or health-related assistance or would prefer assistance,whether the user prefers a particular language for the user’s healthcare providers and documents, and the like. Each of the healthprediction engine 735 and the ranking engine 740 can process the user’sresponses to these questions, as inputted by the call agent 765 in theinteractive interface 768 and update the health outcome predictions andhealth plan rankings accordingly.

In various implementations, the optimizer 742 can further identify anycurrent or future gaps in health care coverage for the user 775 based onthe obtained information from the user 775 and health predictions, suchas a lack of diabetes coverage or a lack of endocrinological care in theuser’s current health care plan. The interactive agent interface 768 canguide the call agent 765 to discuss these gaps in coverage to the user775 and determine whether the user 775 wishes to close these gaps. Thesegaps in coverage may also comprise predicted gaps in coverage based onthe health outcome predictions generated by the health prediction engine735. Thus, the call agent 765 can discuss potential future healthoutcomes and/or future health plan coverage needs with the user 775based on the health predictions and determine whether the user 775wishes to address the predicted health issues with a health care plan717 that provides adequate or superior coverage for the predicted healthoutcomes. As stated herein, the predict health outcomes can comprisepredicted future diagnoses, necessary treatments and/or prescriptions,and the like.

In further examples, the interactive agent interface 768 can present theuser’s current health care plan based on the health record data andprompt the call agent 765 to discuss any shortcomings in the user’scurrent health care plan. The health plan ranking engine 740 can furtheridentify and rank health care plans 717 that provide more effectivecoverage (e.g., higher quality and/or lower out-of-pocket costs). Incertain implementations, the ranking engine 740 can update the healthplan rankings to reflect the user’s preferences. Each health carecoverage plan 717 has a unique set of attributes and benefits, such ascosts, disease coverages, partnerships with health care providers,preferred or available health care facilities and hospitals, doctorselections and/or associations, preventative care services, etc. Asinformation is compiled through input data from the call agent 765 andvia the data compiler 720, the ranking engine 740 can score each of thebenefits and attributes of each health care plan 717 and generate aranking of health care plans 717 in comparison to the user’s currenthealth care plan. Accordingly, the call agent 765 can view a currentranking of health care plans 717 on the interactive interface 768 andcan provide the ranking to the user 775 at any time (e.g., via voice,text message link, email, app or website portal, etc.).

As provided herein, the ranking engine 740 can score health planbenefits and attributes based on affordability (e.g., based on theuser’s current financial information, such as income and expenses),deductibles and copays, familial coverage, the user’s current health(e.g., current treatments, diagnoses, prescriptions, etc.), completing acircle of care for the user 775 and/or user’s family, predicted healthoutcomes for the user 775, and/or the user’s own preferences (e.g., asdetermined via the call session and/or any survey data completed by theuser 775). The user 775 can select from a list of highest ranked healthplans 717 and/or can opt to choose and enroll in any of the listedplans, such as the highest ranked, most optimal health plan 717, whichcan trigger a process between the user 775 can call agent 765 to cancelthe user’s current plan and/or enroll in the selected or most optimalplan 717.

It is contemplated that the health prediction engine 735 and rankingengine 740 can execute one or more machine learning models or artificialintelligence applications to continuously improve their functionsdescribed herein. Such machine learning models and artificialintelligence applications may be tailored and adapted to provideincreasingly effective and/or efficient communications between the callagent 765 and user 775, as well as improved health predictions andhealth plan rankings that are personalized depending on the uniqueattributes of each user 775.

Additionally or alternatively, a user 775 can access a website or launchan application that provides an interactive user interface 778 thatenables the user 775 to provide an authorization input that triggers thedata compiler and translator 720 to obtain and translate the user’shealth records from the health record systems 790 in the mannerdescribed above. The interactive user interface 778 further providesnavigable screens (e.g., similar to the interactive agent interface 768)that prompts the user 775 to verify health records, confirm or selectpharmacy information and preferences, select preferred pharmacies,confirm and/or select prescription medications, confirm doctor and/orclinic information and preferences, select preferred doctors and/orclinics, confirm past and/or current diagnoses, provide additionaldiagnosis information, and the like.

In conjunction with or upon receiving the input data indicating theuser’s selections from the user’s computing device 770, the healthprediction engine 735 can generate a set of health predictions and theranking engine 740 can further perform the health plan benefit andattribute optimizations and rankings for the user 775 in the manner(s)described throughout the present disclosure. The user 775 can viewcomparisons between the ranked health care plans and the user’s currenthealth care plan, including benefit and cost comparisons, and select toenroll in one of the ranked health care plans. Further description ofthe interactive user interface 778 is provided below with respect toFIGS. 8E through 8H.

Example Interactive Agent Interfaces

FIGS. 8A through 8D depict an example interactive agent interface 800presented to a call agent during a call session with a user, accordingto various examples. The interactive agent interface 800 can correspondto the agent interface 768 shown and described with respect to FIG. 7 .The interactive agent interface 800 can be presented to the call agentin conjunction with a call session between the call agent and the user.The interactive agent interface 800 shown in FIG. 8A may be presentedsubsequent to an authorization by the user to obtain the user’s healthrecords, which can trigger the health prediction and health plan rankingtechniques described throughout the present disclosure. Referring toFIG. 8A, the interactive agent interface 800 can provide pharmacyinformation of the user as imported from the user’s health records.During the interaction between the call agent and the user, the callagent can query the user for current pharmacies at which the useracquires prescription medications, as indicated in the prepopulatedfields 802. Based on the user’s confirmations or answers, the call agentcan provide selection inputs on selectable features 804 included on theinteractive interface 800.

In the example shown in FIG. 8A, the interactive interface 800 enablesthe call agent to sort and rearrange the pharmacies imported from theuser’s health records using a filter menu 803. The prepopulated fields802 can include information associated with each listed pharmacy (e.g.,to jog the user’s memory), such as the pharmacy’s name andidentification number, address, and a number of prescriptions filled atthe pharmacy over a given time frame. In some examples, the prepopulatedfields 802 can further indicate anomalies, such as when a listedpharmacy is a long distance from the user’s home location or when apharmacy no longer exists or is not supported by any health care plans.

In further examples, the interactive interface 800 includes a selectablefeature 806 that enables the call agent to remove a particularprescription, such as when the user no longer requires the prescription.The interactive interface 800 can further include a selectable feature808 that enables the call agent to include additional prescriptions notlisted in the prepopulated fields. As provided herein, the selectionsprovided by the call agent can be processed by the health prediction andranking engines described with respect to FIG. 7 .

Referring to FIG. 8B, the interactive agent interface 800 can prompt andguide the call agent to request health-related information from theuser. In one step, the interactive agent interface 800 presents a panel812 that enables the call agent to select whether the user has agreed toprovide information regarding prescription medication coverage (e.g.,the user’s current prescriptions). The interactive interface 800 canfurther include a text box 814 or selectable menu that enables the callagent to input any preferred pharmacies of the user.

In various examples, the interactive agent interface 800 furtherincludes selectable features 816 that guide the call agent to querywhether the user is willing to use a different pharmacy and/or receivemedications by mail (e.g., to save the user money). Once medications areconfirmed and pharmacy details are inputted by the call agent, anindicator 818 is provided to the call agent indicating that prescriptionand pharmacy information from the user has been completed. A doctorselection panel 810 is presented to the call agent to confirm the user’spreferences for doctors. As shown in FIG. 8B, the doctor selection panel820 is prepopulated to include the user’s current doctors and/or clinicsas indicated by the user’s health records, and can include detailsregarding the doctor’s or clinic’s specialty, a number of visits to eachdoctor or clinic over a given time frame, an address of the doctor’sfacilities, and selectable features 822 that enable the call agent toinclude a particular doctor or clinic, or provide an input indicatingthat the doctor or clinic is required for the subsequent health planrankings. As discussed herein, the inputs provided by the call agent canbe processed by the health prediction and ranking engines described inconnection with FIG. 7 .

Referring to FIG. 8C, the interactive interface 800 can include a panelthat guides the call agent in confirming the user’s doctors andprescriptions, and can further include a confirmation feature 832 thatenables the call agent to confirm completion of the user’sprescriptions. In various examples, the interactive interface 800 maypresent a set of prepopulated fields 834, based on the user’s healthrecords, that indicate the user’s past and/or current diagnoses. Thecall agent is prompted to confirm the user’s diagnoses information andprovide selections on selectable features 836 included on theinteractive interface 800 whether the user confirms a current diagnosis.In certain examples, the interactive interface 800 can also include atext feature 838 that enables the call agent to input any additionaldiagnoses that have not been prepopulated on the interface 800 (e.g.,diagnosis information that has not been included in the user’s healthrecords).

Referring to FIG. 8D, the interactive agent interface 800 can present amost optimal health care plan 854 as determined by the health planranking engine based on the health records of the user and the inputsprovided by the call agent during the call session. In certain examples,the optimal health care plan 854 can be presented in comparison to theuser’s current health care plan 852, with a panel 844 indicating furthercomparisons provided for each prioritized benefit of the user. Asdescribed above, the rankings for each of the benefits and attributes ofeach health care plan can be based on the user’s health records,preferences, and the information provided by the user during the callsession as inputted by the call agent into the interactive interface800. As shown in FIG. 8D, the optimal health care plan 854 is parsedinto the highest priority benefits and/or preferences of the user (e.g.,includes all of the user’s preferred doctors at minimal cost).

The rankings and comparisons shown in FIG. 8D can be provided to theuser for review (e.g., via an email or text message link), and the usercan opt to enroll in the optimal plan by selecting an enroll feature846. Alternatively, the call agent may receive a verbal or writtenconfirmation that the user wishes to enroll in the optimal plan, and canperform the enrollment via the interactive interface 800. In furtherexamples, the interactive interface 800 can include a selectable feature848 that enables the call agent or user to view all plans that have beenranking by the ranking engine. Selection of this feature 848 can enablethe call agent and/or user to view each of the ranked plans incomparison to the user’s current plan, which the attributes and benefitsparsed and ranked substantially as shown.

Example Interactive User Interfaces

FIGS. 8E through 8H depict example interactive user interfaces presentedto users to implement one or more processes described herein. Theinteractive user interface 860 can correspond to the user interface 778shown and described with respect to FIG. 7 . The interactive userinterface 860 can be presented to a user of a network-based healthservice via an application or web portal provided on the user’scomputing device 770, as further shown in FIG. 7 . The user interface860 shown in FIG. 8E may be presented subsequent to an authorization bythe user to obtain the user’s health records, which can trigger thehealth prediction and health plan ranking techniques describedthroughout the present disclosure. Referring to FIG. 8E, the userinterface 860 can query the user for information pertaining to theuser’s current and preferred doctors. The interactive user interface 860can be prepopulated with the user’s doctors as identified from theuser’s health records, and the user can provide selection inputsaccordingly.

Referring to FIG. 8F, the interactive user interface 860 can query theuser for information pertaining to the user’s current and/or preferredmedications. The medication list shown in FIG. 8F can likewise beprepopulated based on the user’s health records, and can further enablethe user to provide selection inputs accordingly. FIG. 8G depicts theinteractive user interface 860 querying the user for a preferredpharmacy from pharmacies previously visited by the user. The user canprovide one or more selection inputs accordingly and proceed to a nextscreen or scroll to a next portion of the interactive user interface860. Referring to FIG. 8H, the user is requested to provide informationor confirmations pertaining to current diagnoses. As shown in FIG. 8H,the user can select from a prepopulated list based on the health recordsobtained by the computing system 700 and can add additional diagnosesthat have not been included.

The various inputs and selection provided by the user in the interactiveuser interface 860 shown with respect to FIGS. 8E through 8H can bereceived by the computing system 700 of FIG. 7 as input data, which isprocessed by the health prediction engine 735 and ranking engine 740according to the techniques described herein. Upon performing the healthprediction and health plan ranking techniques, the computing system 700can provide the user with a ranking and comparison screen substantiallysimilar to the interface shown in FIG. 8D. In particular, the rankingand comparison screen can present a ranking of each attribute and/orbenefit of a ranked plan (e.g., a most optimal plan versus the user’scurrent plan), can enable the user to view details pertaining to eachranked benefit and/or attribute (e.g., included doctors, medications,pharmacies, etc.), allow the user to view other ranked plans incomparison to the user’s current plan, and can enable the user to enrollin a particular health care plan.

Methodology

FIG. 9A is a flow chart describing a method of optimizing health plansfor users, according to various examples. In the below discussion ofFIG. 9A, reference may also be made to reference characters representingcertain features and components as shown and described with respect toFIGS. 7, 8A, 8B, 8C, and 8D. Furthermore, the processes described withrespect to FIG. 9A may be performed by a backend computing system 700,agent computing device 767, or a combination of both. Still further,while the steps in FIG. 9A are shown in a specific order, each stepdescribed may be performed prior to, in conjunction with, or subsequentto any other step. Referring to FIG. 9A, the computing system 700 candetect a call session being initiated between a call agent 765 and auser 775 (900). The computing system 700 can further provide data thatenables the call agent 765 computing device 767 to generate theinteractive agent interface 768 for guiding the call agent 767 duringthe call session (905). During the call session, the call agent 765 mayreceive and input the user’s authorization to access and/or obtain theuser’s health records (910).

In various implementations, the computing system 700 can obtain andtranslate the health records of the user 775 (915). As the call sessionprogresses, the computing system 700 can receive input data based on thecall agent’s interactions with the interactive agent interface 768during the call session (920). As described herein, the input data canindicate doctor and health care provider inputs corresponding to theuser’s current and/or preferred doctors and health care facilities, asinputted by the call agent 765 on the interactive interface 800 shown inFIG. 8B (921). The input data can further correspond to prescriptioninputs and preferred or necessary pharmacy inputs provided by the callagent 765 on the interactive interface 800 as shown in FIGS. 8A and 8B(922). The input data can further correspond to diagnoses inputsprovided by call agent 765 on the interactive interface 800 as shown inFIG. 8C (923).

Based on the input data and health records of the user 775, thecomputing system 700 can generate health outcome and health careutilization predictions for the user 775 (925). As described herein, thepredicted health outcomes can correspond to any future diagnoses basedon the user’s current diagnoses, treatments, lab results, and/orprescriptions. As further provided herein, the predicted health careutilization of the user 775 can correspond to the predicted futurehealth care needs of the user 775, which can include any future tests,treatments, prescriptions, facility visits, and health care coverageneeds. The health prediction engine 735 performing such predictionsbased on the input data from the call agent 765 and the user’s healthrecords can do so using machine learning or artificial intelligencetechniques discussed throughout the present disclosure. For example, thehealth prediction engine 735 can execute an artificial intelligenceapplication trained to compare the user’s health records with a corpusof historical health records, filter the historical health records basedon the user’s personal information, such as age, weight, gender,demographic information, genetics, current diagnoses, medications, andthe like. The health prediction engine 735 can identify a set ofmatching health records in which health outcomes are known, and generatea set of probable health outcome predictions for the user 775, which caninclude probabilities for future diagnoses, treatments, prescriptionmedications, lab tests, and the like.

In various examples, the computing system 700 includes a ranking engine740 that can execute an optimizer 742 to rank various health care plans717 and the individual benefits and attributes of the health care plans717 based on the user’s health outcome predictions, health records, andinput data provided by the call agent 765, as described above (930). Thecomputing system 700 may then cause the interactive agent interface 800to present a personalized interface feature indicating ranked healthcare plans optimized for coverage and benefits specific to the user 775(935). In some examples, the interface feature can provide a benefitsand attributes comparison between the most optimal health care plan forthe user 775 and the user’s current health care plan, as shown in FIG.8D. In further examples, the interface feature can further enable thecall agent 765 and/or user 775 to compare other ranked health care planswith the user’s current health care plan. The interface feature mayfurther enable the call agent 765 or user 775 to cancel the user’scurrent health care plan and enroll the user in the most optimal healthcare plan or a plan of the user’s choosing.

FIG. 9B is a flow chart describing another method of optimizing healthplans for users, according to various examples. In the below discussionof FIG. 9B, reference may also be made to reference charactersrepresenting certain features and components as shown and described withrespect to FIGS. 7, 8E, 8F, 8G, 8E, and 8H. Furthermore, the processesdescribed with respect to FIG. 9B may be performed by a backendcomputing system 700, user computing device 770, or a combination ofboth. Still further, while the steps in FIG. 9B are shown in a specificorder, each step described may be performed prior to, in conjunctionwith, or subsequent to any other step. Referring to FIG. 9B, thecomputing system 700 can detect an interactive session on a usercomputing device 770, which can correspond to a user 775 accessing a webportal or health service application (950). The computing system 700 canfurther receive an authorization input to obtain the user’s healthrecords (955). The computing system 700 can then obtain and translatethe health records of the user 775 and prepopulate the interactive userinterface 778 for the user 775 (960).

According to examples provided herein, the computing system 700 canreceive input data based on the user’s interactions with the interactiveuser interface 778 (965). The input data can correspond to the user’sinteractions with the various screens of the interactive user interface860 as shown and described with respect to FIGS. 8E through 8H and caninclude doctor and health care provider inputs (966), prescriptioninputs and preferred or necessary pharmacy inputs (967), and diagnosesinputs (968). Such inputs can correspond to the user’s confirmation ofinformation included in the obtained health records, the user’spreferences pertaining to doctors, health care facilities, pharmacies,and medications, and confirmations of the user’s diagnoses. Based on theinput data and the health records of the user 775, the computing system700 can generate a set of health outcome and health care utilizationpredictions for the user 775 (970). The computing system 700 can furtherprocess the foregoing data by executing an optimizer 742 to rank thevarious benefits and attributes of health care plans 717 for the user775 (975). The computing system 700 can then generate a personalizedinterface feature that indicates ranking data for user optimizedcoverage and benefits (980). As provided herein, the personalizedinterface can enable the user 775 to view ranked benefits and attributesin various health care plans (e.g., a top ten ranking and/or a mostoptimal health care plan) in comparison to the user’s current plan. Thepersonalized interface can further enable the user 775 to selectivelyenroll in a ranked plan.

Call Agent Computing Device

FIG. 10 illustrates a computing device of a call agent communicating inreal time with the computing systems described throughout the presentdisclosure, according to examples described herein. In manyimplementations, the computing device 1000 can comprise a mobilecomputing device, such as a smartphone, tablet computer, laptopcomputer, personal computer, VR or AR headset device, and the like. Incertain examples, the computing device 1000 can include telephonyfeatures such as a microphone 1045, a camera 1050, and a communicationinterface 1010 to communicate with the computing system 1090 over one ormore networks 1080 using any number of wireless communication protocols.

In certain aspects, the computing device 1000 can store a designatedhealth service application in a local memory 1030 that enables thecomputing device 1000 to communicate with the computing system 1090. Thecomputing device 1000 can further access one or more networks 1080 via aweb browser. In variations, the memory 1030 can store additionalapplications executable by one or more processors 1040 of the computingdevice 1000, enabling access and interaction with one or more serversover the one or more networks 1080.

Additionally, the computing device 1000 can be operated by a call agentto perform call sessions with users. In various examples, the call agentcan select the health service application via a user input 1018, whichcan cause the application to be executed by the processor 1040. Inresponse, an interactive agent interface 1042 can be generated on thedisplay screen 1020, which can provide the call agent with all necessaryinformation to perform call sessions as described throughout the presentdisclosure. During a call session, the call agent can provide inputs1018 on an input interface 1025 (e.g., the display screen 1020, akeyboard, a keypad, a mouse, etc.) based on the interactions between thecall agent and a particular user.

As provided herein, the application and or web browser can enable acommunication link over one or more networks 1080 with the computingsystem 1090, such as the computing systems shown and describedthroughout the present disclosure. The processor 1040 can generateinteractive interface features 1042 using content or display datareceived from the computing system 1090 over the network 1080. Asprovided herein, the content data can correspond to prepopulated healthrecord data provided for the call agent, dynamic scripting, health planrankings, health predictions for the user, health record information ofthe user, and any additional personal details of the user receive priorto or during the call session.

User Computing Device

FIG. 11 illustrates a computing device 1100 for communicating with thecomputing systems described throughout the present disclosure, accordingto examples described herein. In many implementations, the computingdevice 1100 can comprise a mobile computing device, such as asmartphone, tablet computer, laptop computer, personal computer, VR orAR headset device, and the like. In certain examples, the computingdevice 1100 can include telephony features such as a microphone 1145, acamera 1150, and a communication interface 1110 to communicate with thecomputing system 1190 using any number of wireless communicationprotocols. The computing device 1100 can further include a positioningmodule 1160 (e.g., GPS) and/or an inertial measurement unit thatincludes one or more accelerometers, gyroscopes, or magnetometers.

In certain aspects, the computing device 1100 can store a designatedhealth service application in a local memory 1130. The computing device1100 can further access one or more networks 1180 via a web browser. Invariations, the memory 1130 can store additional applications executableby one or more processors 1140 of the computing device 1100, enablingaccess and interaction with one or more servers over the one or morenetworks 1180.

Additionally, the computing device 1100 can be operated by a userthrough execution of the health service application or via a website. Invarious examples, the user can select the health service application oraccess a health service website via a user input 1118 on the displayscreen 1120 or input interface 1125, which can cause the application tobe executed by the processor 1140 or the website to be presented on thedisplay screen 1120. In response, an interactive user interface 1142 canbe generated on the display screen 1120, which can provide access to thehealth record compilation, verification, and dispute services, as wellas the health outcome prediction and planning services describedthroughout the present disclosure. Alternatively, the interactiveinterface 1142 can comprise an interactive user interface which the usercan navigate to provide inputs corresponding to the input data describedin connection with FIG. 7 .

As provided herein, the health service application can enable acommunication link over one or more networks 1180 with the computingsystem 1190, such as the computing systems shown and describedthroughout the present disclosure. The processor 1140 can generate userinterface features 1142 using content or display data received from thecomputing system 1190 over the network 1180. As provided herein, thecontent data can correspond to translated health records, verificationand dispute features, health outcome predictions, health planningfeatures, health plan surveys, enrollment features, etc., as describedherein.

Hardware Diagram

FIG. 12 is a block diagram that illustrates a computer system 1200 uponwhich examples described herein may be implemented. A computer system1200 can be implemented on, for example, computer module, computerserver, or a combination of computing device. For example, the computersystem 1200 may be implemented as part of a network-based service, suchas described throughout the present application. In the context of FIGS.1, 4, and 7 the computing systems 100, 400, and 700 may be implementedusing a computer system 1200 such as described by FIG. 12 . While thecomputing systems 100, 400, 700 of FIGS. 1, 4, and 7 are shown asseparate computing systems, as provided herein, the computing systems100, 400, 700 may operate as a single computer system 1200 or acombination of computer systems 1200 as shown and described with respectto FIG. 12 .

In one implementation, the computer system 1200 includes processingresources 1210, a main memory 1220, a read-only memory (ROM) 1230, astorage device 1240, and a communication interface 1250. The computersystem 1200 includes at least one processor 1210 for processinginformation stored in the main memory 1220, such as provided by arandom-access memory (RAM) or other dynamic storage device, for storinginformation and instructions which are executable by the processor 1210.The main memory 1220 also may be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by the processor 1210. The computer system 1200 may alsoinclude ROM 1230 or other static storage device for storing staticinformation and instructions for the processor 1210. A storage device1240, such as a magnetic disk or optical disk, is provided for storinginformation and instructions.

The communication interface 1250 enables the computer system 1200 tocommunicate with one or more networks 1280 (e.g., cellular network)through use of the network link (wireless or wired). Using the networklink, the computer system 1200 can communicate with one or morecomputing devices, one or more servers, and/or one or more databases. Inaccordance with examples provided herein, the memory 1220 can storeexecutable instructions, including record verification and disputeinstructions 1222, health prediction instructions 1224, and healthplanning instructions 1226. In accordance with examples provided herein,the memory 1220 can store executable instructions, including dynamicscripting instructions 1236, health record code translation instructions1238, and health plan ranking instructions 1232. In accordance withexamples provided herein, the memory 1220 can further store contentgenerator instructions 1246. The various instructions may compriseprogrammatic language, machine learning models, artificial intelligence,or any other suitable code for performing the tasks described throughoutthe present disclosure.

By way of example, the instructions and data stored in the memory 1220can be executed by the processor 1210 to implement the functions of anexample computing system of FIGS. 1, 4, and 7 . In various examples, theprocessor 1210 can execute the health record verification and disputeinstructions 1222 to enable a user to verify health records and initiatedisputes, as described above. The processors 1210 can further executethe health prediction instructions 1224 to generate a set of healthoutcome predictions for a user based on the user’s health records, asdescribed above. The processors 1210 can further execute the healthplanning instructions 1226 to generate a set of health plan andlifestyle recommendations, as further described in detail above.

In various examples, the processor 1210 can execute the dynamicscripting instructions 1236 to provide a call agent with a dynamicscript for a call session with a user, as described above. Theprocessors 1210 can further execute the code translation instructions1238 to obtain a user’s health records and automatically translate thecoded records into plain language. The processors 1210 can furtherexecute the health plan ranking instructions 1232 to score the variousattributes of health plans and provide the call agent and/or user with ahealth plan ranking based on all obtained information. The processors1210 can further execute the health prediction instructions 1224 togenerate a set of health outcome predictions for a user based on theuser’s health records, as described above.

In various examples, the processor 1210 can execute the contentgenerator instructions 1246 to prepopulate an interactive agentinterface for a call agent to reference during a call session with auser, as described above. The processors 1210 can further execute thecode translation instructions 1238 to obtain a user’s health records andautomatically translate the coded records into plain language. Theprocessors 1210 can further execute the health plan ranking instructions1232 to score the various attributes of health plans and provide thecall agent and/or user with a health plan ranking based on all obtainedinformation. The processors 1210 can further execute the healthprediction instructions 1224 to generate a set of health outcomepredictions for a user based on the user’s health records, as describedabove.

Examples described herein are related to the use of the computer system1200 for implementing the techniques described herein. According to oneexample, those techniques are performed by the computer system 1200 inresponse to the processor 1210 executing one or more sequences of one ormore instructions contained in the main memory 1220. Such instructionsmay be read into the main memory 1220 from another machine-readablemedium, such as the storage device 1240. Execution of the sequences ofinstructions contained in the main memory 1220 causes the processor 1210to perform the process steps described herein. In alternativeimplementations, hard-wired circuitry may be used in place of or incombination with software instructions to implement examples describedherein. Thus, the examples described are not limited to any specificcombination of hardware circuitry and software.

It is contemplated for examples described herein to extend to individualelements and concepts described herein, independently of other concepts,ideas or systems, as well as for examples to include combinations ofelements recited anywhere in this application. Although examples aredescribed in detail herein with reference to the accompanying drawings,it is to be understood that the concepts are not limited to thoseprecise examples. As such, many modifications and variations will beapparent to practitioners skilled in this art. Accordingly, it isintended that the scope of the concepts be defined by the followingclaims and their equivalents. Furthermore, it is contemplated that aparticular feature described either individually or as part of anexample can be combined with other individually described features, orparts of other examples, even if the other features and examples make nomentioned of the particular feature. Thus, the absence of describingcombinations should not preclude claiming rights to such combinations.

What is claimed is:
 1. A computing system comprising: a networkcommunication interface to communicate, over one or more networks, with(i) health record database systems, and (ii) computing devices of users;one or more processors; and a memory storing instructions that, whenexecuted by the one or more processors, cause the computing system to:based on received user credential information, access a plurality ofheath record systems to obtain a corpus of health records for a user;initiate a health record verification process to enable the user toverify each of the obtained health records; and subsequent to the healthrecord verification, resulting in a verified set of health records forthe user, present, on a display screen of a computing device of theuser, a set of one or more risk mitigation providers or health plansbased at least in part on the verified set of health records of theuser.
 2. The computing device of claim 1, wherein based on a disputeinput from the user for a particular health record, the computing systeminitiates a health record dispute process with a relevant health recordsystem to dispute the particular health record.
 3. The computing systemof claim 1, wherein the health record verification process comprisespresenting, on a display screen of the computing device of the user,each health record in the corpus and prompting the user to verify ordispute the health record.
 4. The computing system of claim 3, whereinpresentation of each health record enables the user to indicate a lackof memory for the health record, and wherein the executed instructionsfurther cause the computing system to: for a specified health record,receive input data indicating that the user lacks memory for thespecified health record; and present one or more memory triggers tostimulate a memory of the user pertaining to the specified healthrecord.
 5. The computing system of claim 2, wherein the dispute processprovides the user with one or more links and/or one or more documentsrequired for disputing the particular health record.
 6. The computingsystem of claim 1, wherein the executed instructions further cause thecomputing system to: based at least in part on the verified set ofhealth records for the user, determine a set of health outcomepredictions for the user.
 7. The computing system of claim 6, whereinthe memory further stores ground truth health data comprisingcorrelations between health records of control group users and actualhealth outcomes of the control group users.
 8. The computing system ofclaim 7, wherein the executed instructions cause the computing system tofurther determine the set of health outcome predictions based on theground truth health data.
 9. The computing system of claim 1, whereinthe executed instructions further cause the computing system to: basedon the verified set of health records of the user, determine one or moreadditional users having similar health issues and/or risks as the user;and provide a social interaction platform enabling the user to contactthe one or more additional users.
 10. The computing system of claim 1,wherein the executed instructions further cause the computing system to:based on the verified set of health records of the user, provideindividually tailored health-related literature to the user.
 11. Thecomputing system of claim 1, wherein the plurality of health recordsystems store the corpus of health records using one or more codeprotocols, and wherein the executed instructions cause the computingsystem to execute code translation logic on the corpus of health recordsin order to generate a plain language corpus of the health records ofthe user.
 12. The computing system of claim 10, wherein the executedinstructions cause the computing system to initiate the health recordverification process using the plain language corpus of the healthrecords of the user.
 13. The computing system of claim 1, wherein theexecuted instructions cause the computing system to further (i) obtainclinical trial data relevant to one or health risks or health issues ofthe user, and (ii) provide a contact feature enabling the user toparticipate in a clinical trial.
 14. The computing system of claim 1,wherein the executed instructions further cause the computing system to:determine one or more adverse factors in the verified set of healthrecords, the one or more adverse factors corresponding to adverseeffects between at least one of prescription medications, healthconditions, or treatments as indicated in the verified set of healthrecords of the user.
 15. The computing system of claim 1, wherein theexecuted instructions further cause the computing system to: determine aset of benefits for the user and provide a recommendation of a healthplan for the user that includes the set of benefits.
 16. The computingsystem of claim 1, wherein the executed instructions further cause thecomputing system to: based at least in part on the verified set ofhealth records for the user, predict at least one of (i) a future set ofprescriptions for the user, or (ii) a future health care usage need forthe user over a predetermined period of time.
 17. The computing systemof claim 1, wherein the executed instructions cause the computing systemto provide the user with a list of recommendations comprising at leastone of (i) foods to avoid, (ii) activities to avoid, (iii) foods toconsume, or (iv) activities to perform.
 18. A non-transitory computerreadable medium storing instructions that, when executed by one or moreprocessors of a computing system, cause the computing system to: basedon received user credential information, access a plurality of heathrecord systems to obtain a corpus of health records for a user; initiatea health record verification process to enable the user to verify eachof the obtained health records; and subsequent to the health recordverification, resulting in a verified set of health records for theuser, present, on a display screen of a computing device of the user, aset of one or more risk mitigation providers or health plans based atleast in part on the verified set of health records of the user.
 19. Thenon-transitory computer readable medium of claim 18, wherein based on adispute input from the user for a particular health record, thecomputing system initiates a health record dispute process with arelevant health record system to dispute the particular health record.20. A computing system comprising: a network communication interface tocommunicate, over one or more networks, with (i) health record databasesystems, and (ii) computing devices of users; one or more processors;and a memory storing instructions that, when executed by the one or moreprocessors, cause the computing system to: based on received usercredential information, access a plurality of heath record systems toobtain a corpus of health records for a user; based on the corpus ofhealth records for the user, predict a set of health outcomes of theuser; and based on the predicted set of health outcomes, determine a setof one or more risk mitigation providers or health plans for the user.